Database Reference
In-Depth Information
0xed945334b49ea005967cd4c48ff0493e2d3ff8d3)
IF NOT EXISTS;
We'll expect this insert to
not
be applied, since we are performing a conditional insert and
there is already a row with the username
frank
. Indeed, Cassandra's feedback for us is
that the insert did not happen:
As with the feedback for a successful application, we see an
[applied]
column, which
tells us the outcome of the lightweight transaction. In the case where a key collision pre-
vented it from being applied, Cassandra also helpfully returns the data in the existing row
with the key we were trying to write to.
Note
For a detailed account of how lightweight transactions are implemented, refer to the
DataStax Cassandra documentation page at
http://www.datastax.com/documentation/cas-
Conditional inserts allow us to protect the data integrity of tables that use a natural
primary key that is not globally unique. However, overwriting existing rows isn't the only
way Cassandra's upsert behavior can get us into trouble.
