cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-4806) Consistency of Append/Prepend on Lists need to be improved or clarified
Date Fri, 23 Nov 2012 14:38:58 GMT


Sylvain Lebresne resolved CASSANDRA-4806.

    Resolution: Fixed

Alright, I've added some precision to the CQL3 doc so closing this.
> Consistency of Append/Prepend on Lists need to be improved or clarified
> -----------------------------------------------------------------------
>                 Key: CASSANDRA-4806
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.2.0 beta 1
>            Reporter: Michaël Figuière
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.0
> Updates are idempotent in Cassandra, this rule makes it simple for developers or client
libraries to deal with retries on error. So far the only exception was counters, and we worked
around it saying they were meant to be used for analytics use cases.
> Now with List datatype to be added in Cassandra 1.2 we have a similar issue as Append
and Prepend operations that can be applied on them are not idempotent. The state of the list
will be unknown whenever a timeout is received from the coordinator node saying that no acknowledge
could be received on time from replicas or when the connection with the coordinator node is
broken while a client wait for an update request to be acknowledged.
> Of course the client can issue a read request on this List in the rare cases when such
an unknown state appear, but this is not really elegant and such a check doesn't come with
any visibility or atomicity guarantees.
> I can see 3 options:
> * Remove Append and Prepend operations. But this is a pity as they're really useful.
> * Make the behavior of these commands quasi-idempotent. I imagine that if we attach the
list of timestamps and/or hashes of recent update requests to each List column stored in Cassandra
we would be able to avoid applying duplicate updates. 
> * Explicitly document these operations as potentially unconsistent under these particular

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message