24fb92c8ba
Most of the analysis of the WHERE clause is done in statement_restrictions. It determines what parts to use for the primary or secondary index, and what parts to use for filtering. The difficult part is that it has a very wide interface. After construction, the user must pick the correct bits from many public functions. There are subtle interactions between them that are hard to untangle. This series simplifies the interface as it is used for selection filtering. In the end, only two public functions are used, both returning expressions: one for the partition-level filtering, one for the clustering row level filtering. In the end, the WHERE clause is factored into three parts: - one part goes into the read_command of the primary or secondary index - another part (that references only partition key columns and static key columns) is used to filter entire partitions - another part (that currently references only clustering key columns and regular columns, but one day may reference other columns) is used to filter clustering rows Refactoring, no backport. Closes scylladb/scylladb#20487 * github.com:scylladb/scylladb: cql3: statement_restrictions: drop accessors for single-column key restrictions cql3: selection: adjust indentation cql3: selection: delete empty loop cql3: statement_restrictions, selection: fold multi-column restrictions into row-level filter cql3: statement_restrictions, selection: merge clustering key filter and regular columns filter cql3: statement_restrictions, selection: merge partition key filter and static columns filter cql3: selection: filter regular and static rows as a single expression each cql3: statement_restrictions: collect regular column and static column filters into single expressions cql3: selection: filter clustering key as a single expression cql3: statement_restrictions: expose filter for clustering key cql3: selection: filter partition key as a single expression cql3: statement_restrictions: expose filter for partition key cql3: statement_restrictions: remove relations used for indexing from filtering cql3: statement_restrictions: bail out of find_idx if !_uses_secondary_index cql3: statement_restrictions, modification_statement: pass correct value of check_indexes cql3: statement_restrictions: correct mismatched clustering/partition restrictions references cql3: statement_restrictions: precalculate get_column_defs_for_filtering() cql3: selection: do_filter(): push static/regular row glue to higher level
Scylla in-source tests.
For details on how to run the tests, see docs/dev/testing.md
Shared C++ utils, libraries are in lib/, for Python - pylib/
alternator - Python tests which connect to a single server and use the DynamoDB API unit, boost, raft - unit tests in C++ cql-pytest - Python tests which connect to a single server and use CQL topology* - tests that set up clusters and add/remove nodes cql - approval tests that use CQL and pre-recorded output rest_api - tests for Scylla REST API Port 9000 scylla-gdb - tests for scylla-gdb.py helper script nodetool - tests for C++ implementation of nodetool
If you can use an existing folder, consider adding your test to it. New folders should be used for new large categories/subsystems, or when the test environment is significantly different from some existing suite, e.g. you plan to start scylladb with different configuration, and you intend to add many tests and would like them to reuse an existing Scylla cluster (clusters can be reused for tests within the same folder).
To add a new folder, create a new directory, and then
copy & edit its suite.ini.