[ https://issues.apache.org/jira/browse/CASSANDRA-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882962#comment-13882962
]
Ondřej Černoš commented on CASSANDRA-6625:
------------------------------------------
[~brandon.williams] Original operations don't set the timestamp explicitly. From user's point
of view the result of batching operations is unexpected and confusing. If you consider this
Not a Problem, so be it, you are the maintainer. But the documentation of batch should state
it explicitly.
Mixing client-generated timestamps with implicit timestamps is fragile and error prone. Batches
therefore provide only limited value and one has to be very careful about the nature of batched
operations; if these have the slightest chance of dealing with the same value, batches need
to stay out.
Sidenote: from my understanding of Cassandra internals I know that fixing this batch misfeature
would be very difficult. So please fix at least the documentation. By no means am I the last
user hitting this wall. Thank you.
> Batch containing delete and insert leads to inconsistent results
> ----------------------------------------------------------------
>
> Key: CASSANDRA-6625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6625
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 1.2.11
> Reporter: Ondřej Černoš
> Priority: Minor
> Labels: cql3
>
> On a single node cluster (i.e. ./bin/cassandra -f on localhost) we ran into the following.
Let's consider empty keyspace with the following table:
> {noformat}
> CREATE TABLE test (
> a varchar,
> b varchar,
> PRIMARY KEY (a, b)
> ) WITH comment='List of a related to b - widerow';
> {noformat}
> The table is empty.
> Now we issue the following batch:
> {noformat}
> BEGIN BATCH
> DELETE FROM test WHERE a = 'a1' AND b = 'b1';
> INSERT INTO test (a, b) VALUES ('a1', 'b1');
> APPLY BATCH;
> {noformat}
> When the batch successfully finishes, the table is empty.
> This is consequence of the fact tombstone wins if timestamps are the same. And they are,
because the operation is batched.
> I consider this a bug. Batching operations shouldn't change the semantics of batched
operations.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
|