cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11907) 2i behaviour is different in different versions
Date Wed, 22 Jun 2016 08:08:58 GMT

    [ 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)

Mime
View raw message