public abstract class CompactTables
extends java.lang.Object
Small utility methods pertaining to the encoding of COMPACT STORAGE tables.
COMPACT STORAGE tables exists mainly for the sake of encoding internally thrift tables (as well as
exposing those tables through CQL). Note that due to these constraints, the internal representation
of compact tables does *not* correspond exactly to their CQL definition.
The internal layout of such tables is such that it can encode any thrift table. That layout is as follow:
CREATE TABLE compact (
key [key_validation_class],
[column_metadata_1] [type1] static,
...,
[column_metadata_n] [type1] static,
column [comparator],
value [default_validation_class]
PRIMARY KEY (key, column)
)
More specifically, the table:
- always has a clustering column and a regular value, which are used to store the "dynamic" thrift columns name and value.
Those are always present because we have no way to know in advance if "dynamic" columns will be inserted or not. Note
that when declared from CQL, compact tables may not have any clustering: in that case, we still have a clustering
defined internally, it is just ignored as far as interacting from CQL is concerned.
- have a static column for every "static" column defined in the thrift "column_metadata". Note that when declaring a compact
table from CQL without any clustering (but some non-PK columns), the columns ends up static internally even though they are
not in the declaration
On variation is that if the table comparator is a CompositeType, then the underlying table will have one clustering column by
element of the CompositeType, but the rest of the layout is as above.
As far as thrift is concerned, one exception to this is super column families, which have a different layout. Namely, a super
column families is encoded with:
CREATE TABLE super (
key [key_validation_class],
super_column_name [comparator],
[column_metadata_1] [type1],
...,
[column_metadata_n] [type1],
"" map<[sub_comparator], [default_validation_class]>
PRIMARY KEY (key, super_column_name)
)
In other words, every super column is encoded by a row. That row has one column for each defined "column_metadata", but it also
has a special map column (whose name is the empty string as this is guaranteed to never conflict with a user-defined
"column_metadata") which stores the super column "dynamic" sub-columns.