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-
Search WWH ::




Custom Search