[
https://issues.apache.org/jira/browse/CASSANDRA-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483306#comment-13483306
]
Edward Capriolo commented on CASSANDRA-4179:
--------------------------------------------
I see that I am probably too late to this discussion, but did want to point out
we may be mis-using the term primary-key here. In my mind the CQL3 compound
primary key is more like the M$ SQL Cluster index, which controls sorting.
This syntax might do more to say "These fields are the primary key" and "these
fields are the ones we sort by".
{noformat}
CREATE TABLE timeline (
name text,
month int,
ts timestamp,
value text,
PRIMARY KEY (name, month),
clustered index (name,month,tx)
)
{noformat}
> 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
> Labels: cql3
> Fix For: 1.2.0 beta 1
>
> Attachments: 4179-2.txt, 4179.txt
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
