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

Reply via email to