Database Reference
In-Depth Information
List columns in column families
The last collection type we'll explore at the column family level is lists. Lists are the most
complex collection types in a couple of ways. As you learned in
Chapter 8
,
Collections,
Tuples, and User-defined Types
, lists have more available mutation operations than maps
or sets. It also turns out that lists have the most complex underlying representation.
Let's take a look at the
shared_by
list in the
user_status_updates
table. Before
we dive into the underlying structure, let's quickly open a cqlsh console and add a new
value to the
shared_by
list of
alice
. When we last left this list, it only had a single
username in it, which isn't really useful for the purposes of our exploration:
UPDATE "user_status_updates"
SET "shared_by" = "shared_by" + ['bob'],
"shared_by" = ['dave'] + "shared_by"
WHERE "username" = 'alice'
AND "id" = 76e7a4d0-e796-11e3-90ce-5f98e903bf02;
Note that, by setting the
shared_by
column twice in our
UPDATE
statement, we can
both prepend and append values to the list in a single query. Having done this, let's take a
look at
alice
's partition in the
user_status_updates
column family, focusing on
the cells related to the
shared_by
collection:
At first glance, the structure looks quite similar to that of set and map columns: the cell
name consists of a clustering column value, a data column name, and finally some other
list-related component. However, what is the list-related component?
It turns out that this value is a UUID; the hex string printed in cassandra-cli is in fact the
usual UUID representation, just without the dashes. If we decode the UUID
e358e-
fe0678711e4ac53f51fa8d64e2e
, the last one in the list, we'll find that it encodes
the timestamp at which we appended
bob
to the list column.