Skip to main content
Source

​
pub async fn update_records<T: KineticaRecord>( &self, table_name: String, expressions: Vec<String>, new_values_maps: Vec<HashMap<String, Option<String>>>, data: Vec<T>, ) -> Result<UpdateRecordsResponse, KineticaError>

Perform predicate-based updates to table data

Runs multiple predicate-based updates in a single call. With the list of given expressions, any matching record’s column values will be updated as provided in new_values_maps. There is also an optional ‘upsert’ capability where if a particular predicate doesn’t match any existing record, then a new record can be inserted.

Note that this operation can only be run on an original table and not on a result view.

This operation can update primary key values. By default only ‘pure primary key’ predicates are allowed when updating primary key values. If the primary key for a table is the column ‘attr1’, then the operation will only accept predicates of the form: “attr1 == ‘foo’” if the attr1 column is being updated. For a composite primary key (e.g. columns ‘attr1’ and ‘attr2’) then this operation will only accept predicates of the form: “(attr1 == ‘foo’) and (attr2 == ‘bar’)”. Meaning, all primary key columns must appear in an equality predicate in the expressions. Furthermore each ‘pure primary key’ predicate must be unique within a given request. These restrictions can be removed by utilizing some available options through options.

The update_on_existing_pk option specifies the record primary key collision policy for tables with a primary key, while ignore_existing_pk specifies the record primary key collision error-suppression policy when those collisions result in the update being rejected. Both are ignored on tables with no primary key.

The records are encoded by the schema of the first.

  • table_name - 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.
  • expressions - A list of the actual predicates, one for each update; format should follow the guidelines here.
  • new_values_maps - 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 expressions.
  • data - The records to send.
Source

​
pub async fn update_records_with_opts<T: KineticaRecord>( &self, table_name: String, expressions: Vec<String>, new_values_maps: Vec<HashMap<String, Option<String>>>, data: Vec<T>, options: UpdateRecordsRequestOptions, ) -> Result<UpdateRecordsResponse, KineticaError>

Perform predicate-based updates to table data

Runs multiple predicate-based updates in a single call. With the list of given expressions, any matching record’s column values will be updated as provided in new_values_maps. There is also an optional ‘upsert’ capability where if a particular predicate doesn’t match any existing record, then a new record can be inserted.

Note that this operation can only be run on an original table and not on a result view.

This operation can update primary key values. By default only ‘pure primary key’ predicates are allowed when updating primary key values. If the primary key for a table is the column ‘attr1’, then the operation will only accept predicates of the form: “attr1 == ‘foo’” if the attr1 column is being updated. For a composite primary key (e.g. columns ‘attr1’ and ‘attr2’) then this operation will only accept predicates of the form: “(attr1 == ‘foo’) and (attr2 == ‘bar’)”. Meaning, all primary key columns must appear in an equality predicate in the expressions. Furthermore each ‘pure primary key’ predicate must be unique within a given request. These restrictions can be removed by utilizing some available options through options.

The update_on_existing_pk option specifies the record primary key collision policy for tables with a primary key, while ignore_existing_pk specifies the record primary key collision error-suppression policy when those collisions result in the update being rejected. Both are ignored on tables with no primary key.

The records are encoded by the schema of the first.

  • table_name - 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.
  • expressions - A list of the actual predicates, one for each update; format should follow the guidelines here.
  • new_values_maps - 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 expressions.
  • data - The records to send.
  • options - The optional parameters; any left unset take the server’s defaults.

Sends a pre-built UpdateRecordsRequest to the /update/records endpoint, its records encoded by the schema of the first.

Sends a pre-built RawUpdateRecordsRequest to the /update/records endpoint, returning the response as the server sends it.

Sends a pre-built RawUpdateRecordsRequest to a specific worker URL, bypassing HA head-node selection. Used for multi-head access.