cql3: Skip indexed column for CK restrictions
When querying an index table, we assemble clustering-column restrictions for that query by going over the base table token, partition columns, and clustering columns. But if one of those columns is the indexed column, there is a problem; the indexed column is the index table's partition key, not clustering key. We end up with invalid clustering slice, which can cause problems downstream. Fix this by skipping the indexed column when assembling the clustering restrictions. Tests: unit (dev) Fixes #7888 Signed-off-by: Dejan Mircevski <dejan@scylladb.com> Closes #8320
This commit is contained in:
committed by
Nadav Har'El
parent
58b7f225ab
commit
0bd201d3ca
@@ -1146,7 +1146,11 @@ query::partition_slice indexed_table_select_statement::get_partition_slice_for_g
|
||||
if (single_ck_restrictions) {
|
||||
auto prefix_restrictions = single_ck_restrictions->get_longest_prefix_restrictions();
|
||||
auto clustering_restrictions_from_base = ::make_shared<restrictions::single_column_clustering_key_restrictions>(_view_schema, *prefix_restrictions);
|
||||
const auto indexed_column = _view_schema->get_column_definition(to_bytes(_index.target_column()));
|
||||
for (auto restriction_it : clustering_restrictions_from_base->restrictions()) {
|
||||
if (restriction_it.first == indexed_column) {
|
||||
continue; // In the index table, the indexed column is the partition (not clustering) key.
|
||||
}
|
||||
clustering_restrictions->merge_with(restriction_it.second);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -280,7 +280,6 @@ def test_allow_filtering_index_in(cql, table2):
|
||||
# single partition. Analogous to CASSANDRA-8302, and also reproduced by
|
||||
# Cassandra's more elaborate test for this issue,
|
||||
# cassandra_tests/validation/entities/frozen_collections_test.py::testClusteringColumnFiltering
|
||||
@pytest.mark.xfail(reason="issue #7888")
|
||||
def test_contains_frozen_collection_ck(cql, test_keyspace):
|
||||
with new_test_table(cql, test_keyspace, "a int, b frozen<map<int, int>>, c int, PRIMARY KEY (a,b,c)") as table:
|
||||
# The CREATE INDEX for c is necessary to reproduce this bug.
|
||||
|
||||
Reference in New Issue
Block a user