cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11907) 2i behaviour is different in different versions
Date Mon, 27 Jun 2016 13:14:52 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350964#comment-15350964
] 

Benjamin Lerer commented on CASSANDRA-11907:
--------------------------------------------

I have the following remarks:
* It seems that the patches for {{2.2}} and {{3.0}} is breaking the behaviour for partition
key restrictions.
The problem can be reproduced with the following test
{code}
    @Test
    public void testIndexQueryWithCompositePartitionKey() throws Throwable
    {
        createTable("CREATE TABLE %s (p1 int, p2 int, v int, PRIMARY KEY ((p1, p2)))");
        createIndex("CREATE INDEX ON %s(v)");

        execute("INSERT INTO %s(p1, p2, v) values (?, ?, ?)", 1, 1, 3);
        execute("INSERT INTO %s(p1, p2, v) values (?, ?, ?)", 1, 2, 3);
        execute("INSERT INTO %s(p1, p2, v) values (?, ?, ?)", 2, 1, 3);

        assertRows(execute("SELECT * FROM %s WHERE p1 = 1 AND v = 3 ALLOW FILTERING"),
                   row(1, 2, 3),
                   row(1, 1, 3));
    }
{code}
* In  the patches for {{2.2}} and {{3.0}}, in {{addIndexExpressionTo}}, I do not really understand
the last part of the statement:
{code}
if (slice != null && !slice.getFirstColumn().equals(restriction.getFirstColumn()))
{code}
I might be mistaken but I do not think that we can have a case where 2 restrictions overlap.
* Same comment for the {{2.1}} patch for:
{code}
if (lastSliceRestriction != null && !restriction.equals(lastSliceRestriction))
{code}
* In {{addIndexExpressionTo}} it seems to me that the 2 first {{if}} statements should be
merged into one.
* I would be in favor of moving the code from {{validate}} into {{StatementRestrictions}}
by making {{PrimaryKeyRestrictionSet}} implements {{Iterable<Restriction>}}.
* In {{testFilteringWithSecondaryIndex}},
{code}
        for (int i = 0; i < 5; i++)
        {
            int j = i + 1;
{code}
can be simplified to:
{code}
        for (int i = 1; i <= 5; i++)
        {
{code}
* 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.
I checked the tests and it does not seems that we have any test that test secondary index
query with two multicolumn slice restrictions. Could you add one?

> 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