https://issues.apache.org/jira/browse/CASSANDRA-3685

On Thu, Dec 29, 2011 at 6:34 PM, Eric Evans <eev...@acunu.com> wrote:
> On Thu, Dec 29, 2011 at 3:44 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
>> 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.
>
> Right, and to get a jump on that bikeshedding I'd propose that look
> something like:
>
> CREATE TABLE test (
>   int(10) text,
>   uuid(92d21d0a-d6cb-437c-9d3f-b67aa733a19f) bigint
> )
>
> or...
>
> CREATE TABLE test (
>   (int)10 text,
>   (uuid)92d21d0a-d6cb-437c-9d3f-b67aa733a19f bigint
> )
>
> But I digress, that's probably best left for another issue and another time. 
> :)
>
>
>> 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)?
>
> --
> 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

Reply via email to