cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5293) formalize that timestamps are epoch-in-micros in 2.0
Date Wed, 27 Feb 2013 11:15:16 GMT


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

> 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