I am confused then. I remember reviewing the source for CQL3 and finding that the row reader used the column count in the CF definition in order to find how many columns it needed to read a single row. I guess I missed a filter over the composited part or that I reviewed an old version.

On 10 July 2012 16:34, Sylvain Lebresne <sylvain@datastax.com> wrote:
On Tue, Jul 10, 2012 at 4:19 PM, Carlos Carrasco <carlos.carrasco@groupalia.com> wrote:
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:
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.


Carlos Carrasco
IT - Software Architect

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