cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "Cassandra2474" by JonathanEllis
Date Fri, 30 Dec 2011 17:02:25 GMT
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:

  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. is created to follow
up on this related problem.
+ Supporting non-utf8 column names is orthogonal to supporting composite columns; will address
that in
  == Alpha ==
@@ -156, +158 @@

      body string,
      posted_by string,    
      PRIMARY KEY(user_id, posted_at, body, posted_by)
+ );
  -- the "sparse" encoding
  CREATE TABLE timeline (
@@ -165, +167 @@

      body string,
      posted_by string,    
      PRIMARY KEY(user_id, posted_at)
+ );
- 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.

View raw message