[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968832#action_12968832
]
Kelvin Kakugawa commented on CASSANDRA-1072:
--------------------------------------------
So, the challenge is that I mirrored the mutation interface for counters.
I have two proposals that I'd like your opinion on:
a) add an optional uuid field to CounterColumn, or
b) add an optional uuid field to CounterMutation that covers the whole mutation.
(b) is not very fine-grained. However, if a batch_add call fails, the client
should retry the whole batch mutation. ntm, uuids are specific to a given
counter, so there won't be any fear of collisions across keys. Although, if a
batch mutation were to update the same key twice (w/in its update_map), the
mutation will have to be collapsed at some point.
note: if we go w/ (a), then CounterUpdate should be refactored out into just a
CounterColumn.
> 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.
