> My use case relied on "mangling" the column names for various
Can you provide details on the use case?
CQL 3 is not locked, the more feedback the better.
> That's not a problem, but I still needed a definitive statement that
> "schema-free tables" (not column families obviously) are now
> impossible within CQL, that I can document in the project as the
> reason for the changes.
AFAIK to be "schema free" you use the "row-column-value" model. While this looks like many
rows it is a single store engine row.
Cheers
-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 30/10/2012, at 8:45 PM, Timmy Turner <timm.turn@gmail.com> wrote:
>> Is your use case covered in the article above ?
>
> My use case relied on "mangling" the column names for various
> purposes, and CQL3 with its transposed columns does of course still
> allow for that, but it means rewriting the part of the application
> that dealt with CQL so it can handle the new syntax/data model.
>
> That's not a problem, but I still needed a definitive statement that
> "schema-free tables" (not column families obviously) are now
> impossible within CQL, that I can document in the project as the
> reason for the changes.
>
>
> Thanks!
>
> 2012/10/30 aaron morton <aaron@thelastpickle.com>:
>> More background http://www.datastax.com/dev/blog/thrift-to-cql3
>>
>> So does this mean that in CQL 3 an explicit schema is absolutely
>> mandatory?
>>
>> Not really, it sort of depends on your view.
>>
>> Lets say this is a "schema free" CF definition in CLI
>>
>> create column family clicks
>> with key_validation_class = UTF8Type
>> and comparator = DateType
>> and default_validation_class = UTF8Type
>>
>> It could be used for wide rows with lots of columns, where the name is a
>> date.
>>
>> As the article at the top says, this CQL 3 DDL is equivalent:
>>
>> CREATE TABLE clicks (
>> key text,
>> column1 timestamp,
>> value text,
>> PRIMARY KEY (key, column)
>> ) WITH COMPACT STORAGE
>>
>> This creates a single row inside C*, column name is a date. The difference
>> is CQL 3 pivots this one "storage engine" row into multiple CQL 3 rows. (See
>> article)
>>
>> So far so good. Let's add some schema:
>>
>> CREATE TABLE clicks (
>> user_id text,
>> click_time timestamp,
>> click_url text,
>> PRIMARY KEY (user_id, click_time)
>> ) WITH COMPACT STORAGE
>>
>> That's functionally the same but has some more schema in it. It tells CQL 3
>> that the label to use for the name of a column is "click_time". Previously
>> the label was "column1".
>>
>>
>> It's now impossible (within CQL) to add new
>> (non-primary-key) columns only for individual rows implicitly with
>> DML-queries (insert/update)?.
>>
>> Is your use case covered in the article above ?
>>
>> Cheers
>>
>> -----------------
>> Aaron Morton
>> Freelance Developer
>> @aaronmorton
>> http://www.thelastpickle.com
>>
>> On 30/10/2012, at 2:31 AM, Timmy Turner <timm.turn@gmail.com> wrote:
>>
>> Thank you! That article helps clear up a lot of my confusion about the
>> changes between CQL 2 and 3, since I was wondering how to
>> access/manipulate CompositeType/DynamicCompositeType columns through
>> CQL.
>>
>> So does this mean that in CQL 3 an explicit schema is absolutely
>> mandatory? It's now impossible (within CQL) to add new
>> (non-primary-key) columns only for individual rows implicitly with
>> DML-queries (insert/update)?.
>>
>>
>>
>>
>> 2012/10/29 Sylvain Lebresne <sylvain@datastax.com>:
>>
>> CQL3 does absolutely allow dynamic column families, but does it
>> differently from CQL2. See
>> http://www.datastax.com/dev/blog/cql3-for-cassandra-experts.
>>
>> --
>> Sylvain
>>
>> On Mon, Oct 29, 2012 at 12:34 PM, Timmy Turner <timm.turn@gmail.com> wrote:
>>
>> Does CQL3 not allow dynamic columns (column names) any more?
>>
>>
|