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