cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ondřej Černoš (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6625) Batch containing delete and insert leads to inconsistent results
Date Mon, 27 Jan 2014 20:10:39 GMT

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

Ondřej Černoš commented on CASSANDRA-6625:
------------------------------------------

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)

Mime
View raw message