cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ramon Nogueira <ra...@echophase.com>
Subject Multi-table CAS batches
Date Wed, 19 Mar 2014 04:31:32 GMT
Referring to this article on the recently added CAS features:
http://www.datastax.com/dev/blog/cql-in-2-0-6

The new CAS batch feature is really cool; are there any plans to support
CAS across column families within a batch? I think this would solve the
same problems solved by the "static columns" feature in a less mind-bending
way. Also, it would allow you to keep the benefits of storing
differently-typed data in different column families and have a homogeneous
logical "row type" per column family while still being able to CAS across
all the data associated with a partition key.

Considering the bills example from the article introducing the feature, it
strikes me as odd that the balance would be associated with the bills table
rather than the users table. Bills do not have a balance - users do. What
if you wanted to use CAS to enforce other constraints when adding/editing
bills e.g. that the balance is above some threshold calculated from other
properties of the user? Yeah you could move all these into static columns
of the bills table as well but that doesn't seem like a very coherent data
model.

Another use case that I can't think of a way to handle with static columns
is as follows: suppose in the above example, you also kept a purchase
history per user. If you wanted to keep the purchase history in sync with
the bills table and the users table (for one user), you'd be out of luck.
You'd have to squash everything into one table with some kind of type token
per CQL row that identifies what kind of data is stored in the row. Not
very far down this road, you lose most of the benefits of CQL in the first
place.

Having a look at the server code it seems (on a very naive first glance)
that it wouldn't be too difficult to add CAS across column families.
Indeed, a lot of it would seem to be just pulling out code that restricts
the update to one CF in the first place, replacing ColumnFamily with
RowMutation for the update.

I'm not proposing CAS reads/conditions be cross-CF - I think this would be
substantially harder although also interesting.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message