[
https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021071#comment-13021071
]
Sylvain Lebresne commented on CASSANDRA-2457:
---------------------------------------------
Attached rebased version (post-CASSANDRA-2454 in particular)
bq. writeLocallyAndReplicate doesn't always perform a local mutation, so it
should probably be renamed
Renamed it to performWrite (since it mostly simply imply a so-called
writePerformer).
bq. Since mutateCounter and writeLocallyAndReplicate are symmetrical and are
called depending on whether an IMutation is an instance of CounterMutation,
could we move them onto IMutation, and polymorphically decide the behavior?
Hum, they are not really so symmetrical. In particular writeLocallyAndReplicate
(or performWrite as it is called nowadays) really is polymorphic over the
IMutation used.
So the only seem we we could do (at least easily) is moving some of
mutateCounter in CounterMutation, but not sure it will look so great. Also, it
is probably nice to keep all the code related to the write/read protocol in
StorageProxy (doing otherwise would be like moving the query code out of
CFStore, nobody wants that :D)
bq. I'm fine with this, since a counter is as "real" a write as any other. But
I do think we should record the latencies for the replicate-on-write stage like
we do for the read and mutation stages on a per column family basis. I can
tackle it in a separate ticket if you'd like.
Make sense, but I'm also in favor of moving this to some other ticket.
> Batch_mutate is broken for counters
> -----------------------------------
>
> Key: CASSANDRA-2457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2457
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.8
>
> Attachments: 0001-Fix-batch_mutate-for-counters-v2.patch,
> 0001-Fix-batch_mutate-for-counters.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> CASSANDRA-2384 allowed for batch_mutate to take counter and non counter
> operation, but the code was not updated correctly to handle that case. As it
> is, the code will use the first mutation in the batch list to decide whether
> to apply the write code path of counter or not, and will thus break if those
> are mixed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
