That's to allow defining column names that are not text/utf8. So you
could have column name "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" be an
actual 128-bit uuid binary value internally, not its string
representation. Put another way, this would affect the CqlMetadata
name_types map.
However, we already have the "column names are always strings"
limitations with existing CQL DDL so it probably makes more sense to
consider it separately from transposition.
On Thu, Dec 29, 2011 at 3:22 PM, Eric Evans <eev...@acunu.com> wrote:
> On Wed, Dec 28, 2011 at 1:05 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
>> Gamma proposal update:
>>
>> The more I think about it the less happy I am with omitting support
>> for sparse columns. Remember that dense composites may only be
>> inserted and deleted, not updated, since they are just a tuple of
>> values with "column names" determined by schema and/or convention.
>>
>> I think we can support sparse columns well in a way that improves the
>> conceptual integrity for the dense composites as well:
>>
>> {code}
>> -- "column" and "value" are sparse; a transposed row will be stored as
>> -- two columns of (user_id, posted_at, 'column': string) and (user_id,
>> posted_at, 'value': blob)
>> CREATE TABLE timeline (
>> user_id int,
>> posted_at uuid,
>> column string,
>> value blob,
>> PRIMARY KEY(user_id, posted_at)
>> ) TRANSPOSED;
>>
>> -- entire transposed row is stored as a single dense composite column
>> -- (series, ts1, cat, subcat, 1337, 92d21d0a-...: []). Note that the
>> -- composite column's value is unused in this case.
>> CREATE TABLE events (
>> series text,
>> ts1 int,
>> cat text,
>> subcat text,
>> "1337" uuid,
>> "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" bigint,
>> PRIMARY KEY(series, ts1, cat, subcat, "1337",
>> "92d21d0a-d6cb-437c-9d3f-b67aa733a19f")
>> ) TRANSPOSED WITH COLUMN NAMES ("1337" int,
>> "92d21d0a-d6cb-437c-9d3f-b67aa733a19f" uuid);
>> {code}
>
> Could you explain what this "TRANSPOSED WITH COLUMN NAMES" syntax does
> (or link to a previous description if I missed it)?
>
>> Thus, columns included in the (transposed) primary key will be
>> "dense," and not updateable, which conforms to our existing practice
>> that keys are not updateable. Remaining columns will be updateable
>> since they will each map to a separate physical column.
>
>
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
