> 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.t...@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 <aa...@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.t...@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 <sylv...@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.t...@gmail.com> wrote: >> >> Does CQL3 not allow dynamic columns (column names) any more? >> >>
