incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
Subject Re: Dynamic CF
Date Tue, 10 Jul 2012 14:34:40 GMT
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

Mime
View raw message