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
