Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Cassandra2474" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/Cassandra2474?action=diff&rev1=7&rev2=8 Tertiary goal: it would be nice to support supercolumns as well as composite columns - == Non-goals == + == Non-goals and related tickets == Supporting DynamicCompositeType or other arbitrarily-and-non-uniformly nested "document" data is a non-goal. https://issues.apache.org/jira/browse/CASSANDRA-3647 is created to follow up on this related problem. + + Supporting non-utf8 column names is orthogonal to supporting composite columns; will address that in https://issues.apache.org/jira/browse/CASSANDRA-3685. == Alpha == @@ -156, +158 @@ body string, posted_by string, PRIMARY KEY(user_id, posted_at, body, posted_by) - ) TRANSPOSED; + ); -- the "sparse" encoding CREATE TABLE timeline ( @@ -165, +167 @@ body string, posted_by string, PRIMARY KEY(user_id, posted_at) - ) TRANSPOSED; + ); }}} - Consideration is also taken for non-String column names: - {{{ - CREATE TABLE events ( - series text, - ts1 int, - cat text, - subcat text, - "1337" uuid, - "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" bigint, - PRIMARY KEY(series, ts1, cat, subcat, "1337", "92d21d0a-d6cb-437c-9d3f-b67aa733a19f") - ) - TRANSPOSED WITH COLUMN NAMES ("1337" int, "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" uuid); - }}} === Examples === `SELECT`, `INSERT`, and `UPDATE` syntax require no changes. Some examples, using the timeline data from the Background section above: @@ -215, +204 @@ The PRIMARY KEY syntax allows for specifying both "sparse" and "dense" data layouts, without the SPARSE keyword that some found unappealing. It also improves conceptual integrity with existing C* practice, namely, that row keys are not update-able. So, the tradeoff is straightforward: include a column in the PRIMARY KEY if you want it to be part of the positional CompositeType tuple (and be more space efficient); leave it out if you want to update it. + Originally a TRANSPOSED WITH [options] syntax was proposed but consensus is that this is weaker than just inferring from the composite PRIMARY KEY definitions. + This also allows supporting SuperColumns, should we choose to do so.
