No such plans. You'd increase contention across tables considerably. On Tue, Mar 18, 2014 at 11:31 PM, Ramon Nogueira <[email protected]> wrote: > 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.
-- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
