cassandra-commits mailing list archives

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


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|]. 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:
>             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}
>     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}
> DELETE FROM test WHERE a = 'a1' AND b = 'b1';
> INSERT INTO test (a, b) VALUES ('a1', 'b1');
> {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

This message was sent by Atlassian JIRA

View raw message