[
https://issues.apache.org/jira/browse/CASSANDRA-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020037#comment-13020037
]
Stu Hood commented on CASSANDRA-2457:
-------------------------------------
* writeLocallyAndReplicate doesn't always perform a local mutation, so it
should probably be renamed
* 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?
> ...and thus this patch remove the latter ones (and count everything in
> writeStat).
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.
PS: Thanks for removing this line!
{code}mutations.iterator().next().getColumnFamilies().iterator().next().metadata().getDefaultValidator().isCommutative(){code}
Thanks Sylvain!
> 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.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
