[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially
[ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-9966: Component/s: CQL > 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: CQL >Reporter: Sam Overton >Priority: Major > Labels: LWT > Fix For: 4.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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially
[ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-9966: Labels: LWT (was: ) > 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 >Reporter: Sam Overton >Priority: Major > Labels: LWT > Fix For: 4.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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially
[ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-9966: Assignee: (was: Sylvain Lebresne) > 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)
[jira] [Updated] (CASSANDRA-9966) Option to apply statements within a batch sequentially
[ https://issues.apache.org/jira/browse/CASSANDRA-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-9966: Summary: Option to apply statements within a batch sequentially (was: batched CAS statements are not serializable) 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 Assignee: Sylvain Lebresne 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)
