Database Reference
In-Depth Information
Displaying the home timeline
Now, let's say
alice
wants to view her home timeline. In the
home_status_update_ids
table, we have a partition that contains exactly what we
need: references to status updates that
alice
is interested in, in the descending order of
creation time. So, to know what status updates we want to display to
alice
, we simply
perform a range query on her partition:
SELECT "status_update_username", "status_update_id"
FROM "home_status_update_ids"
WHERE "timeline_username" = 'alice';
Note that we don't need an explicit
ORDER BY
clause, because we created the table with
descending clustering order: as long as we're working within a single partition, results will
by default be returned in the order we want.
So now we know the primary keys of the status updates we want but we don't have the ac-
tual status updates; those live in the
user_status_updates
table. To actually display
alice
's home timeline, we need to go to that table to retrieve the status updates' content:
SELECT * FROM "user_status_updates"
WHERE "username" IN ('dave', 'carol')
AND "id" IN (
a05b90b0-2ada-11e4-8069-5f98e903bf02,
65cd8320-2ad7-11e4-8069-5f98e903bf02
);
The form that this query takes might be a bit surprising. In reality, we have a collection of
compound primary keys—pairs consisting of
username
and
id
—that we would like to
retrieve from the table. However, the semantics of the
WHERE
clause in our query are dif-