[
https://issues.apache.org/jira/browse/CASSANDRA-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258076#comment-13258076
]
Christoph Tavan commented on CASSANDRA-4176:
--------------------------------------------
We're facing the row-key-sharding-problem as well and our workaround is
concatenating and splitting text-type row keys in our application logic (who
would not work around like that?). However, that feels somehow hacky given the
fact that we can use true CompositeType for the column names, which is a huge
step forward in CQL 3.
Since C* allows row-keys of CompositeType I think it would be a nice feature to
have them supported through CQL as well since it would remove this
concatenation-logic from the application and put it into the data-model where
it belongs.
So +1 for some solution to this from my side.
On the syntax maybe the discussion in CASSANDRA-4004 is also related. I,
personally, think that adding an attribute to the fields that should be part of
the row-key in the {{PRIMARY KEY()}} statement like you suggest would be fine.
> Support for sharding wide rows in CQL 3.0
> -----------------------------------------
>
> Key: CASSANDRA-4176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4176
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Nick Bailey
> Fix For: 1.1.1
>
>
> CQL 3.0 currently has support for defining wide rows by declaring a composite
> primary key. For example:
> {noformat}
> CREATE TABLE timeline (
> user_id varchar,
> tweet_id uuid,
> author varchar,
> body varchar,
> PRIMARY KEY (user_id, tweet_id)
> );
> {noformat}
> It would also be useful to manage sharding a wide row through the cql schema.
> This would require being able to split up the actual row key in the schema
> definition. In the above example you might want to make the row key a
> combination of user_id and day_of_tweet, in order to shard timelines by day.
> This might look something like:
> {noformat}
> CREATE TABLE timeline (
> user_id varchar,
> day_of_tweet date,
> tweet_id uuid,
> author varchar,
> body varchar,
> PRIMARY KEY (user_id REQUIRED, day_of_tweet REQUIRED, tweet_id)
> );
> {noformat}
> Thats probably a terrible attempt at how to structure that in CQL. But I
> think I've gotten the point across. I tagged this for cql 3.0, but I'm
> honestly not sure how much work it might be. As far as I know built in
> support for composite keys is limited.
--
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
