cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6625) Batch containing delete and insert leads to inconsistent results
Date Mon, 27 Jan 2014 17:25:38 GMT


Jonathan Ellis commented on CASSANDRA-6625:

If you're relying on the latency of non-batch operations to guarantee distinct timestamps,
you're in for a nasty surprise at some point.

In other words, it's not batch design that's broken; you're simply doing it wrong.

> 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