cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3761) CQL 3.0
Date Mon, 23 Jan 2012 16:54:40 GMT

    [ 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

        

Mime
View raw message