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
}
That's exactly how CQL3 works. In that example, you would declare:
CREATE TABLE tweet (
UserID text,
When int,
Author text,
Body text,
Lat float,
Long float,
PRIMARY KEY (UserId, When)
)
and that would layout things *exactly* like your Timeline above, but with validation.
The fact that you have to declare Lat and Long does not mean that every CQL row must have them.
much nicer behaviour for model changes and migrations.
Not sure what you mean by that since adding new columns to a CQL3 definition is basically free.
--
Sylvain
