[
https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620144#comment-13620144
]
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: https://issues.apache.org/jira/browse/CASSANDRA-5293
> 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: http://www.atlassian.com/software/jira
