[
https://issues.apache.org/jira/browse/CASSANDRA-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996581#comment-13996581
]
Sylvain Lebresne commented on CASSANDRA-6875:
---------------------------------------------
I haven't looked at that last version yet (but will try to shortly), but
something occured to me. The patch currently use CompositeType for tuple
markers (and thus tuple values must be serialized following CompositeType). We
shouldn't do that. CompositeType is a type that is never used by the native
protocol so 1) it will appear like a "custom type" to drivers and 2) the
composite encoding is inconsistent with the rest of the encodings and in
particular the end-of-component that said encoding contains is completely
useless. This is basically the same problem than CASSANDRA-7209, we shouldn't
commit to such inadequate encoding.
Another way to put it is that this patch introduces the concept of tuple values
in the native protocol, but we don't have such type. So maybe the right way to
go would be to introduce such tuple type first (which would really just be some
form of anymous user type) and use that. Of course, adding such type is even
more out of scope for 2.0 than this ticket already is. So i think we may want
to introduce such tuple type in 2.1 but I suppose we could still commit this to
2.0 but with the right encoding (there is no reason not to reuse the one for
user type from CASSANDRA-7209) and just some simple TupleType (that won't have
more support in 2.0 that what this issue does; it will be exposed to drivers as
a custom type for 2.0 but I don't think there is anything we can do about that
one).
> 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)
