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] [Updated] (CASSANDRA-7346) Explicitly set deletion timestamp to Long.MAX_VALUE for counter deletions
Date Fri, 06 Jun 2014 17:36:03 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-7346:
-----------------------------------------

         Reviewer: Sylvain Lebresne
    Fix Version/s: 2.1.0
          Summary: Explicitly set deletion timestamp to Long.MAX_VALUE for counter deletions
 (was: Row deletes use incompatible timestamps on counter column families)

> Explicitly set deletion timestamp to Long.MAX_VALUE for counter deletions
> -------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7346
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7346
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Richard Low
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> 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