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 Wed, 04 Jul 2012 13:36:34 GMT

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

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

Looking at that more closely, there is a few details on which to decide. At least:
* Do we care about allowing to add new columns to a composite row key? I guess since we decided
to not support it for composite comparators, it's consistent to just say we don't support
it here. But I'll just note that if we want to support it that's not trivial because row key
with one element won't be composite underneath so we won't be able to "extend" them. 
* What about thrift? This require changing key_alias to be key_aliases. Should we just say
that from thrift you can only see/set the first key alias even if there are more than one?
If we do that, working with those table from thrift will be more difficult though. That is
really the same problem that discussed in CASSANDRA-4377, do we care than thrift client might
not have enough information to work with CQL3 table correctly?
                
> 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
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>
> 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