[
https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588230#comment-13588230
]
Sylvain Lebresne commented on CASSANDRA-5293:
---------------------------------------------
Let's play the devil's advocate a bit.
I think that for CQL3, this is already more or less formalized, as timestamp
are optional and are epoch-in-micros when not provided. And I'm clearly fine
being ever move vocal in the documentation that timestamp *have to be*
epoch-in-micros and using that fact (for CQL3 specific features that is).
On the thrift/lower-level storage engine side however, I'm not exactly sure
what you have in mind, but I think it would be nice to at least not break the
existing. Typically, if we're talking of starting to use client timestamps to
do tombstone GC, I'm not sure I'm sold.
Typically, if we're talking of adding a new compaction strategy, and for some
reason, being able to assume epoch-in-micros timestamp really helps, then I'd
be totally fine with that and we could tell "you can't use that if you don't
have epoch-in-micros".
But despite our recommendations, I hightly suspect there is users out there
still not using epoch-in-micros (after all, there is client libraries out there
allowing custom timestamp provider class and that ship with a milli-second
provider (and even a second resolution for at least one of them). It's not the
default but still). And while upgrading to epoch-in-micros from those lower
resolution is theoretically simple, it's fairly costly in practice if you have
to do it "on the spot" (you have to rewrite all the things).
I guess a related question is also, what "complexity and lost opportunities"
are we talking about?
> 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
