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