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.


On 10 July 2012 14:23, Sylvain Lebresne <sylvain@datastax.com> wrote:
On Fri, Jul 6, 2012 at 10:49 PM, Leonid Ilyevsky
<lilyevsky@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:
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

> 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.


Carlos Carrasco
IT - Software Architect

Llull, 95-97, 2 planta, 08005 Barcelona
Skype: carlos.carrasco.groupalia