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 <sylv...@datastax.com> wrote:
> 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
>
--
<http://www.groupalia.com/>Carlos CarrascoIT - Software Architect
Llull, 95-97, 2ยบ planta, 08005 BarcelonaSkype: carlos.carrasco.groupalia
www.groupalia.comcarlos.carra...@groupalia.com
