[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965356#action_12965356
]
Jonathan Ellis commented on CASSANDRA-1072:
-------------------------------------------
In a perfect world I would rather wait to address the remaining -cons before
committing but Kelvin, Johan, and Ryan have been rebasing this for months now
and I don't think it's fair to prolong that pain indefinitely, especially if
we're agreeing that we don't have to preserve backwards-compatibility at the
storage layer when we fix those last issues.
I _would_ like to try to get to a stable client API before we commit though,
for the benefit of other users as well as client authors. There are two fairly
minor points I'd like to address:
- A way to batch increment a counter in a super column (would changing
CounterUpdate to contain a Counter instead of a CounterColumn be all we need
here?)
- Remove the timestamp from CounterUpdate (but keep the struct, because we'll
want to add an optional uuid context for the planned replay support). The
timestamp doesn't make sense to push client-side the way ordinary write
timestamps do, since the conflict resolution is much more complicated and
internal, so let's generate that server side.
> 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.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.
