[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965831#action_12965831
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
I would still made a few changes to this interface:
# CounterUpdate is lacking for batch_add, a CounterMutation should be a
CounterUpdate or a Deletion.
# And since we don't want to expose timestamps to the client for counters, we
should probably have
a specific CounterDeletion struct with no timestamp. For the same reason the
timestamp in remove_counter
should be removed too.
About the deletion/remove, as it turns out it doesn't really work and probably
never will, in that if new increments
follow too closely a remove, the remove could be ignored. I'm fine with keeping
deletions as it (it's still useful, if only to remove definitively a counter)
with a documentation explaining the limitation. But knowing it has limitation,
we could also decide to keep removes restricted to the remove_counter function
and not including it in batch updates. In which case we can get rid of
CounterMutation altogether (and avoid creating a new CounterDeletion struct).
> 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.112210.patch,
> CASSANDRA-1072.120110.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.
