cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Tue, 07 Dec 2010 17:23:20 GMT


Kelvin Kakugawa commented on CASSANDRA-1072:

So, the challenge is that I mirrored the mutation interface for counters.

I have two proposals that I'd like your opinion on:
a) add an optional uuid field to CounterColumn, or
b) add an optional uuid field to CounterMutation that covers the whole mutation.

(b) is not very fine-grained.  However, if a batch_add call fails, the client should retry
the whole batch mutation.  ntm, uuids are specific to a given counter, so there won't be any
fear of collisions across keys.  Although, if a batch mutation were to update the same key
twice (w/in its update_map), the mutation will have to be collapsed at some point.

note: if we go w/ (a), then CounterUpdate should be refactored out into just a CounterColumn.

> Increment counters
> ------------------
>                 Key: CASSANDRA-1072
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Johan Oskarsson
>            Assignee: Kelvin Kakugawa
>         Attachments: CASSANDRA-1072.120610.patch, CASSANDRA-1072.patch,,
> 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message