I'm starting to wonder if another approaches to this wouldn't be simpler. Namely, I'd like to suggest the idea of supporting "static" columns (the initial idea was suggested by jhalliday on irc). That is, we allow to declare some columns that as "static" to a partition, i.e. their value would be shared by all the rows of the same partition. The reason this is related to this issue is that you could CAS those static columns to update multiple rows of the same partition atomically.
Concretely, you could define something like that:
CREATE TABLE t (
id text PRIMARY KEY,
version int static,
PRIMARY KEY (insertion_time, prop1, prop2)
The version column being static, it's value would be shared by all rows having the same id so that you can use it as a "partition version" that allows to serialize inserts. More precisely, you'd read some row(s) of the partition, and update some other row of the partition based on CASing the version just read.
Though it's not 100% equivalent to what the other suggestion of this ticket, I believe this "static" solution would be as general as anything else in terms of what can be done since you can serialize updates in any order you want. And in fact, for every concrete use case I have in mind for this ticket, this static column solution seems to provide a more natural/direct solution (of course, it's quite possible there is use cases I haven't though of and for which this "static columns" idea would be very awkward, but I'd be happy to understand those).
Other advantages of this static columns solution I can think of are that:
- it doesn't require any complex syntax. We'll have to define a few rules to govern those static columns (when do they get deleted, etc..), but syntax wise, it would really all just be the introduction of the "static" keyword in table creation.
- it has uses outside of CAS, making it less of a narrow use case. There are cases where people want to basically cram a static and a dynamic table into a single table for efficiency reasons, and this would provide a "native" way to support that.
I'll soon open a separate issue for this "static columns" idea, with a bit more detail on the exact semantic and some pointers on how I think this can be implemented, but Sebastian Schmidt, is that something which sounds like it would fit well to your use cases? (and if not, can you try to explain why, if only for the sake of better understanding what we're trying to solve here).