[
https://issues.apache.org/jira/browse/CASSANDRA-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15343880#comment-15343880
]
Alex Petrov commented on CASSANDRA-11907:
-----------------------------------------
Even though this type of query is allowed in {{2.1.14}}, unfortunately it
doesn't work there properly as one of the filters is not added:
{code}
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'datacenter1': '1' };
use test;
CREATE TABLE table1 (pk int,c1 int,c2 int,c3 int,v int,PRIMARY KEY (pk,
c1,c2,c3));
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,1);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,1);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,1);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,1);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,2);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,2,2);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,2,2,2);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,2,2,2,2);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,3,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,3,3,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,3,3,3,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,4);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,4,4);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,4,4,4);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,4,4,4,4);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,1,5);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,1,5,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,1,5,5,3);
INSERT INTO table1 (pk,c1,c2,c3,v) VALUES (1,5,5,5,3);
create index table1_v ON table1(v);
cqlsh:test> select * from table1 WHERE pk = 1 AND c1 > 0 AND c1 < 5 AND c2 = 1
AND v = 3 ALLOW FILTERING;
pk | c1 | c2 | c3 | v
----+----+----+----+---
1 | 1 | 1 | 3 | 3
1 | 1 | 1 | 5 | 3
1 | 1 | 3 | 3 | 3
1 | 1 | 5 | 5 | 3
1 | 3 | 3 | 3 | 3
{code}
In order to fix the issue for {{2.2}} and {{3.0}}, I've moved the validation
from {{PrimaryKeyRestrictionSet}} to the special method. Since restrictions are
already given in sorted order, there's no distinction between the previously
existing two error messages (where slice is supplied in preceding column, and
same situation but columns are given out of order), like:
{code}
cqlsh:test> select * from table1 WHERE pk = 1 AND c1 > 0 AND c1 < 5 AND c2 = 1;
InvalidRequest: code=2200 [Invalid query] message="Clustering column "c2"
cannot be restricted (preceding column "c1" is restricted by a non-EQ relation)"
cqlsh:test> select * from table1 WHERE pk = 1 AND c2 = 1 AND c1 > 0 AND c1 < 5;
InvalidRequest: code=2200 [Invalid query] message="PRIMARY KEY column "c2"
cannot be restricted (preceding column "c1" is restricted by a non-EQ relation)"
{code}
Problem is that during creation of {{PrimaryKeyRestrictionSet}} we do not know
if query touches 2i, since 2i restriction might be supplied later (for example,
on "regular" column). So we have to push the validation logic further. Another
problem was that row filter (index expression in 2.x) was not adding all
clustering columns that would require filtering. Trunk branch contains tests
only (with minor removal). Patches for 2.2 and 3.0 are almost identical, but
unfortunately do not merge cleanly.
|[2.2|https://github.com/ifesdjeen/cassandra/tree/9530-2.2]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-9530-2.2-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-9530-2.2-dtest/]
|
|[3.0 |https://github.com/ifesdjeen/cassandra/tree/9530-3.0]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-9530-3.0-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-9530-3.0-dtest/]
|
|[trunk |https://github.com/ifesdjeen/cassandra/tree/9530-trunk]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-9530-trunk-testall/]
| |
> 2i behaviour is different in different versions
> -----------------------------------------------
>
> Key: CASSANDRA-11907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11907
> Project: Cassandra
> Issue Type: Bug
> Reporter: Tommy Stendahl
> Assignee: Alex Petrov
>
> I think I have found more cases where 2i behave different in different
> Cassandra versions, CASSANDRA-11510 solved one such case but I think there
> are a few more.
> I get one behaviour with 2.1.14 and Trunk and I think this is the correct
> one. With 2.2.7 and 3.0.6 the behaviour is different.
> To test this I used ccm to setup one node clusters with the different
> versions, I prepared each cluster with these commands:
> {code:sql}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'datacenter1': '1' };
> CREATE TABLE test.table1 (name text,class int,inter text,foo text,power
> int,PRIMARY KEY (name, class, inter, foo)) WITH CLUSTERING ORDER BY (class
> DESC, inter ASC);
> CREATE INDEX table1_power ON test.table1 (power) ;
> CREATE TABLE test.table2 (name text,class int,inter text,foo text,power
> int,PRIMARY KEY (name, class, inter, foo)) WITH CLUSTERING ORDER BY (class
> DESC, inter ASC);
> CREATE INDEX table2_inter ON test.table2 (inter) ;
> {code}
> I executed two select quieries on each cluster:
> {code:sql}
> SELECT * FROM test.table1 where name='R1' AND class>0 AND class<4 AND
> inter='int1' AND power=18 ALLOW FILTERING;
> SELECT * FROM test.table2 where name='R1' AND class>0 AND class<4 AND
> inter='int1' AND foo='aa' ALLOW FILTERING;
> {code}
> On 2.1.14 and Trunk they where successful. But on 2.2.7 and 3.0.6 they
> failed, the first one with {{InvalidRequest: code=2200 [Invalid query]
> message="Clustering column "inter" cannot be restricted (preceding column
> "class" is restricted by a non-EQ relation)"}} and the second one with
> {{InvalidRequest: code=2200 [Invalid query] message="Clustering column "foo"
> cannot be restricted (preceding column "inter" is restricted by a non-EQ
> relation)"}}.
> I could get the queries to execute successfully on 2.2.7 and 3.0.6 by
> creating two more 2i:
> {code:sql}
> CREATE INDEX table1_inter ON test.table1 (inter) ;
> CREATE INDEX table2_foo ON test.table2 (foo) ;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
