[
https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850234#comment-13850234
]
Sylvain Lebresne commented on CASSANDRA-5633:
---------------------------------------------
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:
{noformat}
CREATE TABLE t (
id text PRIMARY KEY,
version int static,
insertion_time timeuuid,
prop1 text,
prop2 int,
PRIMARY KEY (insertion_time, prop1, prop2)
)
{noformat}
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).
> CQL support for updating multiple rows in a partition using CAS
> ---------------------------------------------------------------
>
> Key: CASSANDRA-5633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5633
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 2.0 beta 1
> Reporter: sankalp kohli
> Assignee: Sylvain Lebresne
> Priority: Minor
> Labels: cql3
> Fix For: 2.0.4
>
>
> This is currently supported via Thrift but not via CQL.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
