cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7346) Row deletes use incompatible timestamps on counter column families
Date Tue, 03 Jun 2014 17:48:02 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14016914#comment-14016914
] 

Aleksey Yeschenko commented on CASSANDRA-7346:
----------------------------------------------

[~rlow] FWIW, that was the approach taken by CASSANDRA-6506 (replacing counter tombstones'
timestamps with Integer.MAX_VALUE, explicitly). This is also was we are most likely to end
up with the second iteration of 6506, anyway (and replace the logical clock with microseconds
since epoch, w/ some corrections if necessary).

So you could say that this issue is ultimately a duplicate of CASSANDRA-6506. That said, I'm
closing it with a 'Not a Problem' for now.

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

Mime
View raw message