[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971745#action_12971745
]
Kelvin Kakugawa commented on CASSANDRA-1072:
--------------------------------------------
Yes, I agree that modifying the value / partitioned counter implementation is
interesting. I thought about it and my original rationale isn't as
strong--optimizing for reads. We could do a lazy optimization that keeps the
calculated total, in memory, after it's been read the first time (invalidating,
after an update).
I think the rest of the comments are reasonable, as well. Although, I've fixed
1830 in this patch months ago. (I should have broken it out into a separate
patch.) And, I'd prefer replicate_on_write, because it *may* be more general.
Although, like you, I don't see a use for it beyond counters, atm.
I'd be happy to fix the above after commit, though. As long as we modify the
value / partitioned counter implementation before 0.7.0 is final.
> 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.121310.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.
