On Fri, Dec 30, 2011 at 10:58 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > I think we're closing in on something workable.
I agree. > Dropping TRANSPOSED from Gamma as redundant with respect to the > composite PRIMARY KEY definition. +1 > Should we support column values in non-sparse rows by adding a > VALUE(column_name) section? I like that. > CREATE TABLE timeline ( > user_id int, > posted_at uuid, > body string, > posted_by string, > PRIMARY KEY(user_id, posted_at, posted_by), > VALUE(body) > ); I think the value declaration also helps in that it's one more thing that provides cues as to the data model it creates (more expressive). But this got me thinking, why not introduce something special for the composite name as well? That way the PRIMARY KEY syntax (which comes preloaded with meaning and expectations) could be kept more SQLish, and the whole thing looks more like an extension to the language as opposed to a modification. Say: CREATE TABLE timeline ( user_id int PRIMARY KEY, posted_at uuid, body text, posted_by text, COMPOSITE_NAME(posted_at, posted_by), COMPOSITE_VALUE(body) ) > (Open to better suggestions for that keyword.) Yeah, same. > On Thu, Dec 29, 2011 at 3:13 PM, Eric Evans <eev...@acunu.com> wrote: >> On Thu, Dec 29, 2011 at 12:04 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >>> I've updated the wiki page at >>> http://wiki.apache.org/cassandra/Cassandra2474 with a more in-depth >>> Background section that hopefully clears up where I'm going with this >>> sparse/dense business. >>> >>> Eric mentioned on IRC that he's uneasy about the PRIMARY KEY syntax >>> implicitly using the first element of PRIMARY KEY as the row key. We >>> could make it explicit with another WITH option to the TRANSPOSED >>> clause: >>> >>> {{{ >>> CREATE TABLE timeline ( >>> user_id int, >>> posted_at uuid, >>> column string, >>> value blob, >>> PRIMARY KEY(user_id, posted_at) >>> ) TRANSPOSED WITH ROW KEY(user_id) >>> }}} >>> >>> This makes things more verbose (this would be a required clause) but >>> I'm okay with that if consensus is that being explicit here is better. >> >> I think that was a reaction to an earlier iteration. Assuming that >> the only place where order matters is in that primary key definition, >> then I think it makes sense without the "... WITH ROW KEY..." bit. >> >> >> >> -- >> Eric Evans >> Acunu | http://www.acunu.com | @acunu > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com -- Eric Evans Acunu | http://www.acunu.com | @acunu
