[
https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747254#comment-14747254
]
Sylvain Lebresne commented on CASSANDRA-9966:
---------------------------------------------
Fyi, it's likely just me being dumb, but I've read twice that previous comment
but have not clue what you are suggesting concretely, nor what you are "not
super happy" with exactly. Some extra precision/clarification would be much
appreciated, at least by me.
> Option to apply statements within a batch sequentially
> ------------------------------------------------------
>
> Key: CASSANDRA-9966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9966
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Sam Overton
> Fix For: 3.x, 2.2.x
>
>
> It is possible to batch CAS statements such that their outcome is different
> to the outcome were they executed sequentially outside of a batch.
> eg.
> a | b | c
> a | 1 | 1
> BEGIN BATCH
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> APPLY BATCH
> results in
> a | b | c
> a | 2 | 2
> If these statements were not batched, the outcome would be
> UPDATE foo SET b=2 WHERE a='a' iF c=1
> a | b | c
> a | 2 | 1
> UPDATE foo SET c=2 WHERE a='a' IF b=1
> applied=false (pre-condition b=1 not met)
> Cassandra already checks for incompatible preconditions within a batch (eg
> one statement with IF c=1 and another statement with IF c=2). It should also
> check for mutations to columns in one statement that affect the
> pre-conditions of another statement, or it should evaluate the statement
> pre-conditions sequentially after applying the mutations of the previous
> statement to an in-memory model of the partition.
> For backwards compatibility this would have to be a new "strict" batch mode,
> eg.
> BEGIN STRICT BATCH
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
