[
https://issues.apache.org/jira/browse/CASSANDRA-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353539#comment-15353539
]
Alex Petrov commented on CASSANDRA-11907:
-----------------------------------------
Thank you for the review!
bq. It seems that the patches for 2.2 and 3.0 is breaking the behaviour for
partition key restrictions.
You're right. I was too concentrated on making slice restrictions compatible
that missed the existing condition. It is now re-added and corresponding test
is in all branches now.
bq. In the patches for 2.2 and 3.0, in {{addIndexExpressionTo}}, I do not
really understand the last part of the statement:
I've simplified this for {{2.2}}, {{3.0}} and {{trunk}}. This turned out to be
redundant for all branches, as using {{!isSlice}} to assign the next position
is sufficient to resolve that correctly. I've made similar change to simplify
{{needsFiltering}.
bq. Same comment for the 2.1 patch ...
(discussed offline, summary here) since we're adding a column multiple times
for the same restriction, we have to check for whether the column is still same
for slice or no.
bq. I would be in favor of moving the code from validate into
StatementRestrictions by making PrimaryKeyRestrictionSet implements
Iterable<Restriction>.
I agree, moved.
bq. In testFilteringWithSecondaryIndex,
Test condition adjusted. It was historically looking different, I should've
optimised it myself.
bq. While looking at MultiColumnRestrictions.Slice::addIndexExpressionTo I
realized that the error message could be confusing if such a restriction was
used within an index query.
Agreed, wording changed to {{Multi-column restrictions can only be applied to a
single set of clustering columns.}} and corresponding tests added
|[2.1|https://github.com/ifesdjeen/cassandra/tree/11907-2.1]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-2.1-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-2.1-dtest/]
|
|[2.2|https://github.com/ifesdjeen/cassandra/tree/11907-2.2]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-2.2-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-2.2-dtest/]
|
|[3.0 |https://github.com/ifesdjeen/cassandra/tree/11907-3.0]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-3.0-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-3.0-dtest/]
|
|[trunk |https://github.com/ifesdjeen/cassandra/tree/11907-trunk]
|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-trunk-testall/]
|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11907-trunk-dtest/]
|
> 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)
