On Tue, Jul 10, 2012 at 4:19 PM, Carlos Carrasco <
carlos.carra...@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
