[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968642#action_12968642
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
bq. np, I thought ahead. CounterMutation is a struct w/ 2 optional fields:
Counter, and Deletion. It basically re-writes CounterMutation as a Mutation.
Sorry, I don't know if I was clear before but I still think there is some
inconsistency between CounterMutation and CounterUpdate. We want to keep
CounterUpdate so we can add an optional uuid in there when we add replay
facilities. But since a CounterMutation takes a Counter and not a
CounterUpdate, we won't be able to have the uuid in there, which will limit the
replay mechanism to {{add}} for no good reason (I think adding the uuid to
CounterMutation directly is the wrong solution because it's not clear the
replay will apply to deletions, plus I think this would be more confusing
anyway). What I'm proposing is simply to have
{noformat}
struct CounterMutation {
1: optional CounterUpdate counter,
2: optional CounterDeletion deletion,
}
{noformat}
Another (very minor) remark is that the comment for CounterUpdate is outdated
(mentions the timestamp).
> 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.
