[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-commits
Subject:    [jira] Commented: (CASSANDRA-1072) Increment counters
From:       "Jonathan Ellis (JIRA)" <jira () apache ! org>
Date:       2010-11-30 19:22:22
Message-ID: 14829263.30521291144942400.JavaMail.jira () thor
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plu \
gin.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.


[prev in list] [next in list] [prev in thread] [next in thread]