[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968955#action_12968955
]
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: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072.120610.patch, CASSANDRA-1072.patch,
> increment_test.py, Partitionedcountersdesigndoc.pdf
>
>
> 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 manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
