[jira] [Commented] (CASSANDRA-7346) Row deletes use incompatible timestamps on counter column families

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ 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)