[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972512#action_12972512
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
Why refactor 1830 in this patch ? To have this broken in a separate method is
purely a matter a taste. Not even saying I don't prefer it, but I think we'd
better keep each ticket focused. And this ticket has enough for himself :)
But that's a detail. And other than that, as said previously I'm fine with
doing the refactor the partitioned counter into the column value post-commit.
Before committing I think it would be nice to do the renaming of
repair_on_write to replicate_on_write (I'm fine with just renaming the public
api for now), to fix the coding style violation and to throw an
InvalidRequestException early in CassandraServer when CL != CL.ONE. If only
because those should be really quick to fix.
But then I'm basically +1 on this (I won't be joignable for the next two weeks
so I figured I'd say it now :)).
> 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.121510.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.
