Denormalizing Data for Maximum Performance - Learning Apache Cassandra - page 126

'carol', 65cd8320-2ad7-11e4-8069-5f98e903bf02,
'carol update 3');
INSERT INTO "home_status_update_ids"
("timeline_username", "status_update_id",
"status_update_username")
VALUES
('alice', 65cd8320-2ad7-11e4-8069-5f98e903bf02, 'carol');
One difference from the previous status update creations jumps out: we're specifying the
id column explicitly, instead of using the NOW() function to generate a timeuuid on-
the-fly. As you'll recall from Chapter 2 , The First Table , INSERT statements do not give
us any feedback: so, if we were to use NOW() , we wouldn't know the UUID that had just
been generated. We could try to find out after the fact by reading the most recent id out
of carol 's partition in the table, but if another process had concurrently created another
status update, we'd get the wrong answer.
We need to know with certainty the id of the new status update, so that we can use it to
create a reference to the status update in carol 's followers' home timelines. So, instead
of using NOW() , we'll generate a UUID in our application. Most languages have perfectly
good built-in or third-party libraries for generating UUIDs; in a pinch, you can use a CQL
query to do it:
SELECT NOW() FROM "user_status_updates" LIMIT 1;
Our choice of user_status_updates is arbitrary. We could use any non-empty table
here, since we're not actually reading any data from the table; rather, we're just exploiting
CQL's willingness to generate UUIDs for us, as shown below:
Returning to our earlier status update creation statements, let's examine the second one.
Here, we're storing a row that contains three pieces of information: the username of a
user who is interested in this status update; the id of the status update; and the user-
name of the author of the status update.