Skip to main content
Source

​
pub async fn filter_by_list( &self, table_name: String, view_name: String, column_values_map: HashMap<String, Vec<String>>, ) -> Result<FilterByListResponse, KineticaError>

Filter a dataset for records with specific column values

Calculates which records from a table have values in the given list for the corresponding column. The operation is synchronous, meaning that a response will not be returned until all the objects are fully available. The response payload provides the count of the resulting set. A new resultant set (view) which satisfies the input filter specification is also created if a view_name is passed in as part of the request.

For example, if a type definition has the columns ‘x’ and ‘y’, then a filter by list query with the column map “x”:[“10.1”, “2.3”], “y”:[“0.0”, “-31.5”, “42.0”] will return the count of all data points whose x and y values match both in the respective x- and y-lists, e.g., “x = 10.1 and y = 0.0”, “x = 2.3 and y = -31.5”, etc. However, a record with “x = 10.1 and y = -31.5” or “x = 2.3 and y = 0.0” would not be returned because the values in the given lists do not correspond.

  • table_name - Name of the table to filter, in [schema_name.]table_name format, using standard name resolution rules. This may be the name of a table or a view (when chaining queries).
  • view_name - If provided, then this will be the name of the view containing the results, in [schema_name.]view_name format, using standard name resolution rules and meeting table naming criteria. Must not be an already existing table or view.
  • column_values_map - List of values for the corresponding column in the table.
Source

​
pub async fn filter_by_list_with_opts( &self, table_name: String, view_name: String, column_values_map: HashMap<String, Vec<String>>, options: FilterByListRequestOptions, ) -> Result<FilterByListResponse, KineticaError>

Filter a dataset for records with specific column values

Calculates which records from a table have values in the given list for the corresponding column. The operation is synchronous, meaning that a response will not be returned until all the objects are fully available. The response payload provides the count of the resulting set. A new resultant set (view) which satisfies the input filter specification is also created if a view_name is passed in as part of the request.

For example, if a type definition has the columns ‘x’ and ‘y’, then a filter by list query with the column map “x”:[“10.1”, “2.3”], “y”:[“0.0”, “-31.5”, “42.0”] will return the count of all data points whose x and y values match both in the respective x- and y-lists, e.g., “x = 10.1 and y = 0.0”, “x = 2.3 and y = -31.5”, etc. However, a record with “x = 10.1 and y = -31.5” or “x = 2.3 and y = 0.0” would not be returned because the values in the given lists do not correspond.

  • table_name - Name of the table to filter, in [schema_name.]table_name format, using standard name resolution rules. This may be the name of a table or a view (when chaining queries).
  • view_name - If provided, then this will be the name of the view containing the results, in [schema_name.]view_name format, using standard name resolution rules and meeting table naming criteria. Must not be an already existing table or view.
  • column_values_map - List of values for the corresponding column in the table.
  • options - The optional parameters; any left unset take the server’s defaults.

Sends a pre-built FilterByListRequest to the /filter/bylist endpoint.

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