[jira] [Comment Edited] (CASSANDRA-6625) Batch containing delete and insert leads to inconsistent results

["Ondřej Černoš (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883223#comment-13883223 ] 

Ondřej Černoš edited comment on CASSANDRA-6625 at 1/27/14 8:10 PM:
-------------------------------------------------------------------

If operations on the same tcp connection are not strongly ordered, then you should definitely update your [documentation|http://cassandra.apache.org/doc/cql3/CQL.html#updateStmt]. It should rather read: do not use server-side generated timestamps unless your operations do not need to be ordered, even if you issue them synchronously in serial order. Googling ordering in Cassandra reveals nil, timestamp treatment in CQL doc on both Apache site and Datastax site is very limited.


was (Author: ondrej.cernos):
If operations on the same tcp connection are not strongly ordered, then you should definitely update your [documentation|http://cassandra.apache.org/doc/cql3/CQL.html#updateStmt]. It should rather read: do not use server-side generated timestamps unless your operations do not need to be ordered, even if you issue them in synchronously in serial order. Googling ordering in Cassandra reveals nil, timestamp treatment in CQL doc on both Apache site and Datastax site is very limited.

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