At this point, we've seen that you can look up rows by partition key alone, or by a combination of a partition key and a clustering column. We can easily imagine other ways to use WHERE, but it's not as flexible as we might hope.
In Chapter 3, Organizing Related Data, you learned that any row in a table is uniquely identified by the combined values of its primary key columns. However, in the case of user_status_updates, the role of the username column is superfluous for the purposes of uniqueness; since id is a UUID, we know that it alone will uniquely identify the row on its own.
So, can we skip the username partition key and just look up rows by the id clustering column? Let's give it a shot:
SELECT * FROM "user_status_updates" WHERE id = 3f9b5f00-e8f7-11e3-9211-5f98e903bf02;
This query is a syntactically valid CQL, and the WHERE clause identifies an existing row in the table - specifically, the status update whose body reads...