update_records

Name of table to be updated, in [schema_name.]table_name format, using standard name resolution rules. Must be a currently existing table and not a view.

A list of the actual predicates, one for each update; format should follow the guidelines here. The user can provide a single element (which will be automatically promoted to a list internally) or a list.

List of new values for the matching records. Each element is a map with (key, value) pairs where the keys are the names of the columns whose values are to be updated; the values are the new values. The number of elements in the list should match the length of input parameter expressions. The user can provide a single element (which will be automatically promoted to a list internally) or a list.

An optional list of new binary-avro encoded records to insert, one for each update. If one of input parameter expressions does not yield a matching record to be updated, then the corresponding element from this list will be added to the table. The default value is an empty list ( [] ). The user can provide a single element (which will be automatically promoted to a list internally) or a list.

An optional list of JSON encoded objects to insert, one for each update, to be added if the particular update did not match any objects. The default value is an empty list ( [] ). The user can provide a single element (which will be automatically promoted to a list internally) or a list.

Identifies which of input parameter records_to_insert and input parameter records_to_insert_str should be used. Allowed values are:

• binary

• json

The default value is ‘binary’.

Optional parameters. Allowed keys are:

• global_expression – An optional global expression to reduce the search space of the predicates listed in input parameter expressions. The default value is ‘’.

• bypass_safety_checks – When set to true, all predicates are available for primary key updates. Keep in mind that it is possible to destroy data in this case, since a single predicate may match multiple objects (potentially all of records of a table), and then updating all of those records to have the same primary key will, due to the primary key uniqueness constraints, effectively delete all but one of those updated records. Allowed values are:

  • true

  • false

  The default value is ‘false’.

• error_handling – Specifies how record errors are handled during the update’s reinsert (including any alternate insert records supplied via input parameter records_to_insert). When set, this option is authoritative for the reinsert. Primary-key collision behavior is governed by update_on_existing_pk and ignore_existing_pk. Allowed values are:

  • permissive – Records with bad column values are kept when possible: the offending column is filled with its default value if one exists, otherwise with null if the column is nullable; if neither is possible the record is skipped and reported.

  • skip – Records with bad values are skipped and reported; the rest of the batch is applied.

  • abort – Stops the update and rejects the remaining batch when any record is incorrect.

  The default value is ‘abort’.

• update_on_existing_pk – Specifies the record collision policy for updating a table with a primary key. There are two ways that a record collision can occur.

  The first is an “update collision”, which happens when the update changes the value of the updated record’s primary key, and that new primary key already exists as the primary key of another record in the table.

  The second is an “insert collision”, which occurs when a given filter in input parameter expressions finds no records to update, and the alternate insert record given in input parameter records_to_insert (or input parameter records_to_insert_str) contains a primary key matching that of an existing record in the table.

  If update_on_existing_pk is set to true, “update collisions” will result in the existing record collided into being removed and the record updated with values specified in input parameter new_values_maps taking its place; “insert collisions” will result in the collided-into record being updated with the values in input parameter records_to_insert / input parameter records_to_insert_str (if given).

  If set to false, the existing collided-into record will remain unchanged, while the update will be rejected and the error handled as determined by ignore_existing_pk. If the specified table does not have a primary key, then this option has no effect. Allowed values are:

  • true – Overwrite the collided-into record when updating a record’s primary key or inserting an alternate record causes a primary key collision between the record being updated/inserted and another existing record in the table

  • false – Reject updates which cause primary key collisions between the record being updated/inserted and an existing record in the table

  The default value is ‘false’.

• pk_conflict_predicate_higher – The record with higher value for the column resolves the primary-key insert conflict. The default value is ‘’.

• pk_conflict_predicate_lower – The record with lower value for the column resolves the primary-key insert conflict. The default value is ‘’.

• ignore_existing_pk – Specifies the record collision error-suppression policy for updating a table with a primary key, only used when primary key record collisions are rejected (update_on_existing_pk is false). If set to true, any record update that is rejected for resulting in a primary key collision with an existing table record will be ignored with no error generated. If false, the rejection of any update for resulting in a primary key collision will cause an error to be reported. If the specified table does not have a primary key or if update_on_existing_pk is true, then this option has no effect. Allowed values are:

  • true – Ignore updates that result in primary key collisions with existing records.

  • false – Treat as errors any updates that result in primary key collisions with existing records.

  The default value is ‘false’.

• update_partition – Force qualifying records to be deleted and reinserted so their partition membership will be reevaluated. Allowed values are:

  • true

  • false

  The default value is ‘false’.

• enable_inplace_updates – If set to true, qualifying records are modified in place. If set to false, they are updated by deleting the existing record and inserting a replacement (delete and insert), which prevents the change from being reflected in dependent materialized views until they are refreshed. Allowed values are:

  • true

  • false

  The default value is ‘true’.

• enable_worker_oop_update – For an out-of-place update (delete and insert), controls where the replacement records are reinserted. If set to true, the workers that own the data reinsert them directly, avoiding a round trip through the head node; a shard-key change reshards the replacements to their new owning workers. If set to false, the replacement records are reinserted from the head node. Overrides the feature.enable_worker_oop_update@ configuration default. Allowed values are:

  • true

  • false

• truncate_strings – If set to true, any strings which are too long for their charN string fields will be truncated to fit. Allowed values are:

  • true

  • false

  The default value is ‘false’.

• use_expressions_in_new_values_maps – When set to true, all new values in input parameter new_values_maps are considered as expression values. When set to false, all new values in input parameter new_values_maps are considered as constants. NOTE: When true, string constants will need to be quoted to avoid being evaluated as expressions. Allowed values are:

  • true

  • false

  The default value is ‘false’.

• record_id – ID of a single record to be updated (returned in the call to GPUdb.insert_records() or GPUdb.get_records_from_collection()).

The default value is an empty dict ( ).

A RecordType object using which the binary data will be encoded. If None, then it is assumed that the data is already encoded, and no further encoding will occur. Default is None.