cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcin Szymaniuk (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
Date Tue, 18 Nov 2014 00:29:35 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marcin Szymaniuk updated CASSANDRA-7281:
----------------------------------------
    Attachment: 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch

This patch makes the tuple query working

There are two concerns though:
1.  I don't get why we have the last line assert in testMultipleClusteringReversedComponents.
The fact result set is not empty  now seem to be correct to me.

2. Not sure about validateSlices. The way slices are represented makes it fail sometimes.
Not sure if it's a bug in my code or I the validation is not correct anymore. Here is example
of validate failing:

create table foo (a int, b int, c int, d int , e int, PRIMARY KEY (a, b, c, d, e) )
            WITH CLUSTERING ORDER BY (b DESC, c ASC, d ASC, e DESC);

SELECT * FROM foo WHERE a=0 AND (b, c, d, e) > (0, 1, 1, 0);

I transform this restriction to 4 independent restrictions:
b>0
b=0 c=1 d=1 e>0
b=0 c=1 c>1
b=0 c>1
when we create slices out of it it ends up as:
slices = [[, 000400000000ff], [000400000000000004000000010000040000000100, 000400000000000004000000010000040000000100000400000000ff],
[000400000000000004000000010000040000000101, 0004000000000000040000000101], [0004000000000000040000000101,
00040000000001]]

so slices[2][1]==slices[3][0] which seems fine to me (maybe not optimal?)

then this condition in validateSlices make it fail:
if (i > 0 && comparator.compare(slices[i - 1].finish, start) >= 0)

In the patch I commented out the problematic condition in validation and the query works.
If the validation is still valid I will have to fix the code but I need some sugestions. 
Also I have bunch of dtests. Do I submit them independently?






> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7281
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>             Fix For: 2.0.12
>
>         Attachments: 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
>
>
> As noted on [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
the tuple notation is broken when the clustering order mixes ASC and DESC directives because
the range of data they describe don't correspond to a single continuous slice internally.
To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH CLUSTERING
ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
>  a | b | c
> ---+---+---
>  0 | 2 | 0
>  0 | 1 | 0
>  0 | 1 | 1
>  0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
>  a | b | c
> ---+---+---
>  0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe that with
more clustering columns we may have more slices.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message