Peeking Under the Hood - Learning Apache Cassandra - page 273

Compound primary keys in column
families
Now that we've established the relatively familiar-looking column family structure of
users —a table with a simple primary key—let's move on to a table with a compound
primary key. To start, let's take a look at home_status_updates , a fairly straightfor-
ward table. Recall that this table has a partition key timeline_username ; a clustering
column status_update_id ; and two data columns, body and
status_update_username column.
We'll use the LIST command to take a look at the contents of the column family and, be-
forehand, we'll use the ASSUME command to set the value output format to utf8 . This has
a similar effect as the AS modifier we used earlier, but it applies to all cells in a column
family, rather than only cells with a specific name:
ASSUME home_status_updates VALIDATOR AS utf8;
LIST home_status_updates;
The output of the LIST command takes the same general shape as that for the users
column family, but the way the information is arranged might come as a surprise:
The output contains only a single RowKey , that is alice ; it contains six cells with rather
inscrutable names. Recall that in the Fully denormalizing the home timeline section of
Chapter 6 , Denormalizing Data for Maximum Performance , we populated the
home_status_updates table with two status updates, both in alice 's partition of the
table. So how does the information in the column family line up with the information in the
CQL table we're used to?
To answer this question, look closely at the names of the cells. Take the second cell, which
has the name 16e2f240-2afa-11e4-8069-5f98e903bf02 :body. This cell name