cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4179) Add more general support for composites (to row key, column value)
Date Mon, 23 Apr 2012 17:40:34 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259761#comment-13259761
] 

Sylvain Lebresne commented on CASSANDRA-4179:
---------------------------------------------

On the 'does support for composite in the column value make sense' question, I'll add that
supporting them would potentially make for a nicer upgrade for people coming from thrift/CQL2
that already use composites as the defaultValidator. Not sure if that's really common though,
and we should add support *just because of that*, but that's still a additional slight pro
for adding it.
                
> Add more general support for composites (to row key, column value)
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-4179
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4179
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>            Reporter: Sylvain Lebresne
>             Fix For: 1.1.1
>
>
> Currently CQL3 have a nice syntax for using composites in the column name (it's more
than that in fact, it creates a whole new abstraction but let's say I'm talking implementation
here). There is however 2 other place where composites could be used (again implementation
wise): the row key and the column value. This ticket proposes to explore which of those make
sense for CQL3 and how.
> For the row key, I really think that CQL support makes sense. It's very common (and useful)
to want to stuff composite information in a row key. Sharding a time serie (CASSANDRA-4176)
is probably the best example but there is other.
> For the column value it is less clear. CQL3 makes it very transparent and convenient
to store multiple related values into multiple columns so maybe composites in a column value
is much less needed. I do still see two cases for which it could be handy:
> # to save some disk/memory space, if you do know it makes no sense to insert/read two
value separatly.
> # if you want to enforce that two values should not be inserted separatly. I.e. to enforce
a form of "constraint" to avoid programatic error.
> Those are not widely useful things, but my reasoning is that if whatever syntax we come
up for "grouping" row key in a composite trivially extends to column values, why not support
it.
> As for syntax I have 3 suggestions (that are just that, suggestions):
> # If we only care about allowing grouping for row keys:
> {noformat}
> CREATE TABLE timeline (
>     name text,
>     month int,
>     ts timestamp,
>     value text,
>     PRIMARY KEY ((name, month), ts)
> )
> {noformat}
> # A syntax that could work for both grouping in row key and colum value:
> {noformat}
> CREATE TABLE timeline (
>     name text,
>     month int,
>     ts timestamp,
>     value1 text,
>     value2 text,
>     GROUP (name, month) as key,
>     GROUP (value1, value2),
>     PRIMARY KEY (key, ts)
> )
> {noformat}
> # An alternative to the preceding one:
> {noformat}
> CREATE TABLE timeline (
>     name text,
>     month int,
>     ts timestamp,
>     value1 text,
>     value2 text,
>     GROUP (name, month) as key,
>     GROUP (value1, value2),
>     PRIMARY KEY (key, ts)
> ) WITH GROUP (name, month) AS key
>    AND GROUP (value1, value2)
> {noformat}

--
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