[
https://issues.apache.org/jira/browse/CASSANDRA-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084602#comment-14084602
]
Sylvain Lebresne commented on CASSANDRA-7537:
---------------------------------------------
The reason is CASSANDRA-6069. I'll note that the point 2 of my
[comment|https://issues.apache.org/jira/browse/CASSANDRA-6069?focusedCommentId=13774535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13774535]
at the time is not longer valid, we do support batch for CAS now.
It should be possible to change the code so that we preserve the same timestamp
for every "user" mutation but still special case collection deletions as
per-CASSANDRA-6069 but I don't see an easy way to not make it damn ugly. Is the
current behaviour such a big problem in practice (given that you can't control
the timestamps of a CAS operation anyway)?
> Updates and partition tombstones are not given the same timestamp in a CAS
> batch
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-7537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7537
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Nicolas Favre-Felix
>
> Create a table with one partition and 2 CQL rows:
> {code}
> CREATE TABLE t1 (
> k text,
> c text,
> v text,
> PRIMARY KEY(k,c)
> );
> BEGIN BATCH
> INSERT INTO t1 (k,c,v) VALUES ('x','1','1');
> INSERT INTO t1 (k,c,v) VALUES ('x','2','2');
> APPLY BATCH;
> {code}
> CAS-delete the full partition based on the expected value of a single column:
> {code}
> cqlsh:ks1> SELECT * FROM t1 WHERE k='x';
> k | c | v
> ---+---+---
> x | 1 | 1
> x | 2 | 2
> (2 rows)
> cqlsh:ks1> BEGIN BATCH
> ... UPDATE t1 SET v = '0' WHERE k = 'x' AND c = '1' IF v = '1';
> ... DELETE FROM t1 WHERE k = 'x';
> ... APPLY BATCH;
> [applied]
> -----------
> True
> cqlsh:ks1> SELECT * FROM t1 WHERE k='x';
> k | c | v
> ---+---+---
> x | 1 | 0
> (1 rows)
> {code}
> sstable2json reports that the updated column has a timestamp 1 greater than
> the partition delete:
> {code}
> {"key": "78","metadata": {"deletionInfo":
> {"markedForDeleteAt":1405097039224999,"localDeletionTime":1405097039}},"columns":
> [["1:v","0",1405097039225000]]}
> {code}
> All mutations in a CAS batch should be applied with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
