cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Tue, 07 Dec 2010 20:35:20 GMT


Sylvain Lebresne commented on CASSANDRA-1072:

Hum indeed. In theory I think I prefer (a). It "feels" better and it is indeed more fine grained
(and we won't have to care about what to do if a batch_add update multiple times the same
counter, though it's not really a big problem). The only downside is that we return a CounterColumn
from a get and we will never fill the uuid in that situation (even if the user provides one
on add). It's probably ok since the uuid will be optional but still, this mean that for a
CounterColumn c that use a uuid, we won't have c = get(add(c)), which may be slightly surprising
to users at first.

Despite that, I still think that my own preference goes to (a) (since I don't see any other
clearly better alternative on the top of my hat). And I agree that CounterUpdate could go
away then. 

> Increment counters
> ------------------
>                 Key: CASSANDRA-1072
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Johan Oskarsson
>            Assignee: Kelvin Kakugawa
>         Attachments: CASSANDRA-1072.120610.patch, CASSANDRA-1072.patch,,
> Break out the increment counters out of CASSANDRA-580. Classes are shared between the
two features but without the plain version vector code the changeset becomes smaller and more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message