[
https://issues.apache.org/jira/browse/CASSANDRA-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191249#comment-13191249
]
Sylvain Lebresne commented on CASSANDRA-3761:
---------------------------------------------
bq. so I suggest instead just disallowing range queries on row keys for non-OPP
for now.
I don't disagree, but I'll note that the problem is the same for indexed
queries. We can only allow full-ring range slices however (maybe that's what
you meant); i.e. disallow having a non-equal restriction on the row key, but
allow to have no restrictions at all. As a side I'll note that imho that's yet
one more reason to spit PK in two (the argument being that when you start
having too many different restrictions on the first component of the PK and the
others, maybe it's worth acknowledging it in the syntax).
bq. My inclination would be if we're going to ignore it, let's set it to
something obviously bogus, like -1
Sure. For some reason I cannot really explain I wanted to avoid 0 and went with
1, but -1 is better.
bq. I have to admit I'm not a huge fan of the Restriction class
As the comments in the code says, I'm not an absolute fan either, but it was
still the best I could come up at the time. The goal being to make validation
and querying as fast as possible. I'm open to suggestions for a better
encapsulation though.
bq. What is CFDefinition.Name trying to encapsulate?
It's representing what I could call for lack of a better name a 'CQL column
name'. I.e, the name of one of the definition in the CREATE TABLE definition.
And in the case of Compact Storage, one of those 'CQL column name' happens to
be the name for the C* value the record represent. So yes, there is some clash
of terminology: a CQL column can be, in C*, one of: the row key, the columm
name, a component of the colum name or the column value. Again, I'm open to
suggestions to better names that avoid the confusion.
bq. "Name value" declaration confuses me
So to complete my comment above, you can see CFDefinition as the correspondence
between the CQL names defined in the CREATE TABLE and what they represent
internally. 'Name value' is the name used to represent the C* value in the
COMPACT STORAGE case. Maybe calling it value_alias would avoid the confusion?
(I avoided calling them 'alias' at first, because from the CQL standpoing, they
are not mere aliases but actual (CQL) column names).
bq. 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.
Yes but internally a dynamic CF don't use a composite, so it is bound to have
some differences internally. That being said, now that I think about it, I
should be able to make those differences even smaller by pushing them inside
the CompositeType.Builder. That'll probably also merge a few differences
between sparse and static.
Now that remind me of a detail that is worth mentioning. In the current patch,
if you declare the following:
{noformat}
CREATE TABLE foo (key text, col text, value text, PRIMARY KEY (key, col)) WITH
COMPACT STORAGE;
{noformat}
and you do a {{SELECT * FROM foo WHERE key = 'k'}}, then it'll return all the
record for key 'k'. But if now you declare:
{noformat}
CREATE TABLE foo (key text, col1 text, col2 text, value text, PRIMARY KEY (key,
col1, col2)) WITH COMPACT STORAGE;
{noformat}
and do {{SELECT * FROM foo WHERE key = 'k' AND col1 = 'c'}}, then you will only
get one record back, the one where col1 is 'c' and col2 is not defined, if it
exists, not all the record that have as prefix col1 == 'c'. The reason being
that for dense, we allow to have only a prefix of the key to be defined, and so
you can do:
{noformat}
INSERT INTO foo (key, col1) VALUES ('k', 'c')
{noformat}
One option would be to disallow doing this, but it would add an actual
limitation to what is possible.
> 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
