[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966879#comment-14966879
]
Benjamin Lerer commented on CASSANDRA-7281:
-------------------------------------------
Sorry for not reviewing the patch sooner.
Your patch suffer from the same problem as I mentionned earlier. It will not
work with a mix of single and multi column restrictions like:
{{SELECT * FROM myTable WHERE partitionKey = 1 AND clustering_1 IN (1, 2) AND
clustering_2 = 0 AND (clustering_3, clustering_4) > (2, 3);}}
Another problem is that a big part of the code in {{PrimaryKeyRestrictionSet}}
is relative to {{MultiColumnRestrictions}} and should be in my opinion
encapsulate within it. Having this code within {{PrimaryKeyRestrictionSet}}
will make the implementation of an issue like CASSANDRA-8855 much more
complicated.
I have pushed modified version of the patch for 2.2
[here|https://github.com/apache/cassandra/compare/trunk...blerer:7281-2.2] (it
runs fine on CI).
Feel free to provide some feedbacks on it.
> 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
> Assignee: Marcin Szymaniuk
> Fix For: 2.1.x
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v2.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v3.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v4.patch,
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-v5.patch,
> 7281_unit_tests.txt
>
>
> 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)
