[
https://issues.apache.org/jira/browse/CASSANDRA-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191188#comment-13191188
]
Jonathan Ellis commented on CASSANDRA-3761:
-------------------------------------------
Looking at SS.multiRangeSlice: I think we should address the key/token problem
as well: CQL < 3 silently turns a "key >= X" into "token(key) >= token(X)".
This is not what users will expect, since many of the rows returned will not in
fact satisfy the requested key inequality. I've opened CASSANDRA-3771 for this
-- I don't think we'll get consensus in time to incorporate that here, so I
suggest instead just disallowing range queries on row keys for non-OPP for now.
We can add one in later without breaking anything, and in the meantime, Hadoop
can continue to page via Thrift. (See discussion on CASSANDRA-2878.)
I don't understand the comment here:
{code}
sliceRange.count = 1; // We use this for range slices, where the
count is ignored in favor of the global column count
{code}
My inclination would be if we're going to ignore it, let's set it to something
obviously bogus, like -1.
I have to admit I'm not a huge fan of the Restriction class. Some additional
encapsulation might help there since "r == null || !r.isEquality()" checks seem
scattered around right now.
What is CFDefinition.Name trying to encapsulate? "Name value" declaration
confuses me. :)
In my mind a classic, dynamic CF is the simplest possible dense, not a separate
type. So I'm not sure the distinction of Kind.dynamic is useful. (I note that
you already have these as the same case in SS.process.)
Nit: it's more clear to avoid double-negatives, as in the if/else in {{if
(!isKeyRange()) ... else ...}}. Similar nit in ... lots of places. :)
> CQL 3.0
> -------
>
> Key: CASSANDRA-3761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3761
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 1.1
>
> Attachments: 0001-CQL-3.0.patch,
> 0002-Add-support-for-switching-the-CQL-version.patch,
> 0003-Makes-batches-atomic.patch, 0004-Thrift-gen-files.patch, cql_tests.py,
> create_cf_syntaxes.txt
>
>
> This ticket is a reformulation/generalization of CASSANDRA-2474. The core
> change of CQL 3.0 is to introduce the new syntaxes that were discussed in
> CASSANDRA-2474 that allow to:
> # Provide a better/more native support for wide rows, using the idea of
> transposed vie.
> # The generalization to composite columns.
> The attached text file create_cf_syntaxes.txt recall the new syntaxes
> introduced.
> The changes proposed above allow (and strongly suggest in some cases) a
> number of other changes to the language that this ticket proposes to
> explore/implement (more details coming in the comments).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
