Beyond Key-Value Lookup - Learning Apache Cassandra - page 76

Restricting by part of a partition key
Our status_update_replies table has a two-column partition key consisting of
status_update_username and status_update_id . In some cases, we may
want to, for instance, retrieve all of the replies to a certain user's status updates. It would
be nice if we could query by part of the partition key.
Let's insert a row into status_update_replies , and then try to retrieve it using
only the status_update_username column:
INSERT INTO "status_update_replies"
("status_update_username", "status_update_id", "id", "body")
VALUES(
'alice',
76e7a4d0-e796-11e3-90ce-5f98e903bf02,
NOW(),
'Good luck!'
);
Let's take a look at the table contents:
SELECT * FROM "status_update_replies"
WHERE "status_update_username" = 'alice';
As it turns out, this is also illegal:
This error message tells us that if we're going to restrict any part of the partition key, we
need to restrict all of it. This constraint is necessary because the layout of partition keys in
a table is not related to their semantic ordering: instead, they're organized using the hash-
like token of each key that we encountered in Chapter 2 , The First Table . So, rows that
contain alice in the status_update_username column will be distributed evenly
through the partition key space; Cassandra doesn't have any way of knowing where to find
them.