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}
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.
(I've updated the wiki page.)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
