> Agreed. I actually flip between cli and cqlsh these days. Only tables created with COMPACT STORAGE are visible to cassandra-cli (in fact visible to any thrift based client).
This article helps http://www.datastax.com/dev/blog/cql3-for-cassandra-experts > Is there still a way to have composite row keys ? It's coming. In this example: CREATE TABLE seen_ships ( day text, time_seen timestamp, shipname text, PRIMARY KEY (day, time_seen) ); http://www.datastax.com/dev/blog/whats-new-in-cql-3-0 * day is the internal row key * there is only ONE internal column / cell, the shipname * the internal column / cell "shipname" is a composite of the *value* of time_seen. e.g. <time_seen:shipnae> Hope that helps. ----------------- Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 23/12/2012, at 2:00 PM, Pierre-Yves Ritschard <p...@spootnik.org> wrote: > Is there still a way to have composite row keys ? > There are times when you want to partition wide rows by a tuple instead of > pushing the composites into column names. > > Lists could do the trick but would not allow multiple types and aren't > allowed as primary keys anyhow. > > At some point I remember seeing a "token" syntax, is that still supposed to > make it to 1.2 ? > > > > > > On Sat, Dec 22, 2012 at 1:38 PM, Brian O'Neill <b...@alumni.brown.edu> wrote: > > Agreed. I actually flip between cli and cqlsh these days. > > cqlsh shows the logical view. > cli shows the physical view. > > This is useful, especially when developing using a thrift-based client. > Here are the slides and video if you want to have a look. > > -brian > > > > On Dec 22, 2012, at 3:36 AM, Wz1975 wrote: > >> You still add one row. The column name is the remaining part of the >> composite key (repeat for each column) plus each of the column which is not >> in the composite key. I found it is much clearer to look at the data through >> Cassandra -cli which shows you how data is stored. >> >> >> Thanks. >> -Wei >> >> Sent from my Samsung smartphone on AT&T >> >> >> -------- Original message -------- >> Subject: CQL3 Compound Primary Keys - Do I have the right idea? >> From: Adam Venturella <aventure...@gmail.com> >> To: user@cassandra.apache.org >> CC: >> >> >> Trying to better grasp compound primary keys and what they are conceptually >> doing under the hood. When you create a table with a compound primary key in >> cql3 (http://www.datastax.com/dev/blog/schema-in-cassandra-1-1) the first >> part of the key is the partition key. I get that and the subsequent parts >> help with the row name as I understand it. >> >> So when you add a new row to that columnfamily/table, you are still adding a >> row. In other words, the RandomPartitioner places it somewhere in the >> cluster as a row on it's own as opposed to just adding a new column to an >> existing row, which would live on the same node as the row >> >> The effect of the compound key means that those rows are effectively treated >> as if they were part of the same column, making it a wide column. >> >> Is that the right idea or do I have the row / rp thing wrong? >> > > > Brian ONeill > Lead Architect, Health Market Science (http://healthmarketscience.com) > mobile:215.588.6024 > blog: http://weblogs.java.net/blog/boneill42/ > blog: http://brianoneill.blogspot.com/ > >
