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] [Comment Edited] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
Date Tue, 26 May 2015 09:40:18 GMT

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

Benjamin Lerer edited comment on CASSANDRA-7281 at 5/26/15 9:39 AM:
--------------------------------------------------------------------

Thanks for the patch. It is nice that you added all those unit tests.

I had a quick look at the patch and I have the following comments:
# CASSANDRA-8613 has changed the way things are working. You can now have a mix tulpe relations
and non tulpe relations. This means that you first relation might not be a tulpe relation
or a slice tulpe relation.
# In 2.2 {{SelectStatement}} has been refactored to simplify the code and allow us to implements
more complex features. Your approach of creating new restrictions will not fit properly there.

I believe that you should be able to skip this restrictions creation step and implements the
logic into {{buildBound}} by going directly from the original restriction to the composites.
 
FYI: The {{buildBond}} unit tests are located in {{SelectStatementTest}}.


was (Author: blerer):
Thanks for the patch. It is nice that you added all those unit tests.

I had a quick look at the patch and I have the following comments:
# CASSANDRA-8613 has changed the way things are working. You can now have a mix a tulpe relations
and non tulpe relations. This means that you first relation might not be a tulpe relation
or a slice tulpe relation.
# In 2.2 {{SelectStatement}} has been refactored to simplify the code and allow us to implements
more complex features. Your approach of creating new restrictions will not fit properly there.

I believe that you should be able to skip this restrictions creation step and implements the
logic into {{buildBound}} by going directly from the original restriction to the composites.
 
FYI: The {{buildBond}} unit tests are located in {{SelectStatementTest}}.

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