[
https://issues.apache.org/jira/browse/CASSANDRA-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14016550#comment-14016550
]
Sylvain Lebresne commented on CASSANDRA-7346:
---------------------------------------------
bq. If you know you have stopped incs, then delete, then start again (with
some external synchronization) then deleting is fine.
Actually, fyi, I don't think that's true because there is no guarantee that
subsequent update will end up being ultimately merged (by compaction) in the
order they were received by the replica. You could even theoretically have the
case where it looks like everything worked properly (i.e. you get only
post-delete stuff accounted for) for a while, and then a compaction ends up
compacting the pre and post increment but not the delete and _pouf_ you get a
corrupted value.
Which btw is not to say that using milliseconds for counter timestamps was on
purpose, it's definitively an oversight that has persisted somehow. But we had
discussed the idea of making the current behaviour more "official" by making
counter deletes use Integer.MAX_VALUE. The rational being, if you try to
increment-delete-increment, if the post-increment don't work, you might be
surprised initially, but at least it makes it clear that something doesn't
work. If doing an increment-delete-increment kind-of works in simple testing,
it's easy to miss the fact that counter deletes are broken and to get bitten
later on. Given that even with external synchronization you can't really
guarantee that increment post-delete will work as said above, I'm tempted to go
with the more clearly-broken-so-you-don-t-get-bitten-badly-later behaviour.
> Row deletes use incompatible timestamps on counter column families
> ------------------------------------------------------------------
>
> Key: CASSANDRA-7346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7346
> Project: Cassandra
> Issue Type: Bug
> Reporter: Richard Low
>
> For counters, timestamps are automatically computed to be milliseconds since
> the epoch. For everything else, when not specified manually, they are
> microseconds since the epoch. This means if you delete a counter row,
> subsequent updates are lost unexpectedly.
> I know that deleting counters is not recommended, but that's only because
> deletes and incs don't commute. If you know you have stopped incs, then
> delete, then start again (with some external synchronization) then deleting
> is fine.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
