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 Tue, 28 Jun 2016 19:03:57 GMT

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

Mime
View raw message