[
https://issues.apache.org/jira/browse/CASSANDRA-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993078#comment-13993078
]
Tyler Hobbs commented on CASSANDRA-6875:
----------------------------------------
Okay, most of your concerns should be addressed on the [same
branch|https://github.com/thobbs/cassandra/compare/3808c2b35993fed50554f13a73b2444afb598715...CASSANDRA-6875-2.0].
As I mentioned, I've kept the same behavior for slices over mixed-asc/desc
comparators; I'll wait for your response to decide what to do about that.
Tuples.Value no longer returns serialized values, so {{buildBounds}} takes care
of that work. It seemed cleanest to just split out different functions for
building the different types of multi-column bounds instead of fitting it all
into one loop.
I did try moving MultiColumnRestrictions into a separate attribute in
SelectStatement, but that didn't seem to make things much clearer. The column
names that the restriction applies to would need to be separately tracked.
When processing restrictions, you would have to refer back to that list and
check it or update it. I think the current behavior is reasonably clear if you
think of it like this: SelectStatement.columnRestrictions tracks restrictions
on each column; in the case of multi-column restrictions, some columns may
share a single restriction object.
Once ASF mail is working again, I'll start that thread about tests on the dev
ML.
> 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)
