cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Bridges (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5293) formalize that timestamps are epoch-in-micros in 2.0
Date Tue, 02 Apr 2013 19:11:15 GMT


Sean Bridges commented on CASSANDRA-5293:

This will break a lot of our code as we use non epoch-in-micro values as timestamps quite
a bit.  It is very handy for ensuring order when you have another monotonically increasing
id available.  

As an example we compute meta data for versioned objects, and store the meta data in cassandra.
 The version id is a monotonically increasing long, and we write the meta data to cassandra
with a timestamp of the version id.  Due to retries, multiple machines may be processing the
same object with different version ids, but since we always write to cassandra with a timestamp
of the version id, the latest version id always wins.

We have a couple other use cases, but having a user set timestamp that does not have to be
an epoch-in-micros is very useful.

If you want a real timestamp, perhaps it is better to add a new timestamp-micros field which
is set by the co-ordinator, and not visible to thrift/cql.
> formalize that timestamps are epoch-in-micros in 2.0
> ----------------------------------------------------
>                 Key: CASSANDRA-5293
>                 URL:
>             Project: Cassandra
>          Issue Type: Task
>          Components: Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0
> We've worked around "don't assume timestamps are actually timestamps" but the utility
is not worth the complexity and lost opportunities to optimize this imposes.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message