I think he means something like having a fixed set of coiumns in the table definition, then in the actual rows having other columns not specified in the defintion, indepentent of the composited part of the PK. When I reviewed CQL3 for using in Gossie[1] I realized I couldn't have this, and that it would complicate things like migrations or optional columns. For this reason I didn't use CQL3 and instead wrote a row unmaper that detects the discontinuities in the composited part and uses those as the boundaries for the individual concrete rows stored in a wide row [2]. For example:
Given a Timeline table defined as key validation UTF8Type, column name validation CompositeType(LongType, AsciiType), value validation BytesType: Timeline: { user1: { 1341933021000000: { Author: "Tom", Body: "Hey!" }, 1341933022000000: { Author: "Paul", Body: "Nice", Lat: 40.0, Lon: 20.0 }, 1341933023000000: { Author: "Lana", Body: "Cool" } }, ... } Both of the following structs are valid and will be able to be unmaped from the wide row "user1": type Tweet struct { UserID string `cf:"Timeline" key:"UserID" cols:"When"` When int64 Author string Body string } type GeoTweet struct { UserID string `cf:"Timeline" key:"UserID" cols:"When"` When int64 Author string Body string Lat float32 Lon float32 } Granted I lose database-side validation over the individual column values (BytesType) but in exchange I get very flexible rows and much nicer behaviour for model changes and migrations. 1: https://github.com/carloscm/gossie 2: https://github.com/carloscm/gossie/blob/master/src/gossie/mapping.go#L339 On 10 July 2012 14:23, Sylvain Lebresne <sylv...@datastax.com> wrote: > On Fri, Jul 6, 2012 at 10:49 PM, Leonid Ilyevsky > <lilyev...@mooncapital.com> wrote: > > At this point I am really confused about what direction Cassandra is > going. CQL 3 has the benefit of composite keys, but no dynamic columns. > > I thought, the whole point of Cassandra was to provide dynamic tables. > > CQL3 absolutely provide "dynamic tables"/wide rows, the syntax is just > different. The typical example for wide rows is a time serie, for > instance keeping all the events for a given event_kind in the same C* > row ordered by time. You declare that in CQL3 using: > CREATE TABLE events ( > event_kind text, > time timestamp, > event_name text, > event_details text, > PRIMARY KEY (event_kind, time) > ) > > The important part in such definition is that one CQL row (i.e a given > event_kind, time, event_name, even_details) does not map to an internal > Cassandra row. More precisely, all events sharing the same event_kind will > be > in the same internal row. This is a wide row/dynamic table in the sense of > thrift. > > > > I need to have a huge table to store market quotes, and be able to query > it by name and timestamp (t1 <= t <= t2), therefore I wanted the composite > key. > > Loading data to such table using prepared statements (CQL 3-based) was > very slow, because it makes a server call for each row. > > You should use a BATCH statement which is the equivalent to batch_mutate. > > -- > Sylvain > -- <http://www.groupalia.com/>Carlos CarrascoIT - Software Architect Llull, 95-97, 2ยบ planta, 08005 BarcelonaSkype: carlos.carrasco.groupalia www.groupalia.comcarlos.carra...@groupalia.com