[
https://issues.apache.org/jira/browse/CASSANDRA-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987526#comment-13987526
]
Sylvain Lebresne commented on CASSANDRA-6875:
---------------------------------------------
I don't disagree, the split I'm suggesting is not absolutely future proof, and
we'll need to find something better in the long run. But that don't change the
fact that storing multi-column restriction in an array when we only use one is
misleading and error prone as of this patch imo. I mainly meant the splitting
as a way to support what we do support today more cleanly, but I do absolutely
think SelectStatement will require much serious refactoring sooner than later.
There's CASSANDRA-4762 too that we will want to get at some point (which, it's
worth mentioning, is made slightly less urgent by this ticket because it covers
some of the same cases, though it's not fully equivalent) that will complicate
matters here.
So anyway, I'm all for a third option that is both clean and future proof, but
I'm coming short here right now. Or rather, I see ways to get there, but they
require more refactoring than is reasonable for a 2.0 target. So I went with
the suggestion that felt cleaner, if not too future proof :). But if you prefer
not do the class splitting, I can live with that as long as we maybe split
buildBound and add some comments.
> CQL3: select multiple CQL rows in a single partition using IN
> -------------------------------------------------------------
>
> Key: CASSANDRA-6875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6875
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Nicolas Favre-Felix
> Assignee: Tyler Hobbs
> Priority: Minor
> Fix For: 2.0.8
>
>
> In the spirit of CASSANDRA-4851 and to bring CQL to parity with Thrift, it is
> important to support reading several distinct CQL rows from a given partition
> using a distinct set of "coordinates" for these rows within the partition.
> CASSANDRA-4851 introduced a range scan over the multi-dimensional space of
> clustering keys. We also need to support a "multi-get" of CQL rows,
> potentially using the "IN" keyword to define a set of clustering keys to
> fetch at once.
> (reusing the same example\:)
> Consider the following table:
> {code}
> CREATE TABLE test (
> k int,
> c1 int,
> c2 int,
> PRIMARY KEY (k, c1, c2)
> );
> {code}
> with the following data:
> {code}
> k | c1 | c2
> ---+----+----
> 0 | 0 | 0
> 0 | 0 | 1
> 0 | 1 | 0
> 0 | 1 | 1
> {code}
> We can fetch a single row or a range of rows, but not a set of them:
> {code}
> > SELECT * FROM test WHERE k = 0 AND (c1, c2) IN ((0, 0), (1,1)) ;
> Bad Request: line 1:54 missing EOF at ','
> {code}
> Supporting this syntax would return:
> {code}
> k | c1 | c2
> ---+----+----
> 0 | 0 | 0
> 0 | 1 | 1
> {code}
> Being able to fetch these two CQL rows in a single read is important to
> maintain partition-level isolation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
