cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
Date Tue, 17 Dec 2013 08:24:09 GMT

    [ 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)

Mime
View raw message