Static-only inserts

As it turns out, inserting a row that consists only of static data is perfectly valid. Let's say, we relax our rule that upon signing up, a user must also write their first status update. If bob wishes to sign up, he may simply enter a username, e-mail, and password:

INSERT INTO "users_with_status_updates" 
("username", "email", "encrypted_password") 
VALUES ( 
  'bob', 
  'bob@gmail.com', 
  0x10920941a69549d33aaee6116ed1f47e19b8e713 
);

Now, we have an email and an encrypted_password associated with the partition key bob but no clustering column values forming rows under that partition key. So, can we retrieve the information about bob that we just inserted? As it turns out, we can. Here's the updated state of the table that can be retrieved using the SELECT * FROM "users_with_status_updates"; statement:

We do, indeed, see username and email of bob, but we also notice something odd: the id column—part of the table's primary key—is null! This is because the row with the username value bob is essentially a synthetic row, representing the data associated with a partition key that has no actual rows. To satisfy ourselves of this fact, let's add a status update for bob:

INSERT INTO "users_with_status_updates" 
("username", "id", "body") 
VALUES ('bob', NOW(), 'Bob status update');

Now, let's take a look at the table again with the help of the SELECT * FROM "users_with_status_updates"; statement:

The row with the id value null has disappeared since the synthetic construct is no longer necessary. We now have access to static column values of bob via a real row.

For more information about static columns, visit the page in the DataStax CQL reference at http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/refStaticCol.html.