cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
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:
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.
  

Mime
View raw message