Automatically generating UUIDs

In the status updates we've created so far, we used predetermined UUIDs that were generated on May 29, 2014. For this reason, the timestamp encoded in the UUIDs doesn't really tell us anything useful about when the rows were created. However, in the general case, we would like to encode useful data in the UUID, and in particular, the timestamp at which the row itself was created.

Libraries that generate Version 1 UUIDs are available for just about any programming language, but Cassandra also gives us a built-in CQL function to generate a UUID from the current time, the NOW function. Let's use that function to insert a few new status updates:

INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('alice', NOW(), 'Alice Update 1'); 
INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('bob', NOW(), 'Bob Update 1'); 
INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('alice', NOW(), 'Alice Update 2'); 
INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('bob', NOW(), 'Bob Update 2'); 
INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('alice', NOW(), 'Alice Update 3'); 
INSERT INTO "user_status_updates" ("username", "id", "body") 
VALUES ('bob', NOW(), 'Bob Update 3');

Instead of explicitly specifying a UUID constant for the id field, we used the NOW function to generate a new and unique UUID for each row we inserted.

While the NOW function is quite convenient, particularly in the CQL shell, it comes with one major downside. Since a CQL INSERT statement does not give any feedback on the results of the operation, you won't actually know what UUID the NOW function generates. Sometimes, this is fine; but in many cases, your application would want to perform further business logic that requires knowing the primary key of the record that was just created. In these cases, it's better to use a library to generate UUIDs at the application level and provide them explicitly as literals in the INSERT statement.

Now that we've got a handful of rows in the user_status_updates table, let's take a look at its contents:

SELECT "username", "id", "body", UNIXTIMESTAMPOF("id") 
FROM "user_status_updates";

As we did previously, we'll ask Cassandra to return the millisecond-precision timestamp of the UUIDs in the table along with the data in all columns. Let's take a look at the results:

We notice a couple of interesting things here. First, we can see that the results are grouped by username: all the status updates of bob appear first, followed by all the status updates of alice. This is despite the fact that we interleaved the status updates of alice and bob when we inserted them.

Second, within each user's status updates, the updates are returned in ascending order of the timestamp of the row's id column. Looking at the rightmost column in the results, we see that the timestamps monotonically increase for each user. This is no coincidence; the id column determines the ordering of rows in the user_status_updates table, and since it's a timeuuid column, the timestamp encoded in the UUID determines the semantic ordering of the rows.