cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4284) Improve timeuuid <-> date relationship
Date Thu, 12 Jul 2012 16:29:35 GMT


paul cannon commented on CASSANDRA-4284:

bq. I'm not sure I follow, could you give an example.

I just meant that since uuid1 represents 100-nanosecond time precision instead of full seconds,
but our time syntax only allows specification of full seconds (i.e.:

2012-07-12 15:11:19+0000

), we could extend it to allow things like

2012-07-12 15:11:19.8810219+0000

But that wouldn't allow for specification of all the extra bits, leaving the randomness problem
intact (if somewhat less visible). And I definitely do appreciate the desire to avoid confusing
situations, so I suppose the % syntax makes sense. It's going to need to be kinda verbose,
though; we have 62 bits to account for, even if we allow fractional seconds as above. So,
for example:

2012-07-12 15:11:19.8810219+0000 %2d826ed5b67249fc

..uniquely specifies UUID {{d5b7b46b-cc33-11e1-ad82-6ed5b67249fc}}.
> Improve timeuuid <-> date relationship
> --------------------------------------
>                 Key: CASSANDRA-4284
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.1.0
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql3
>             Fix For: 1.2
> We added timeuuid to CQL3, whose purpose is to provide a collision-free timestamp basically
and as a convenience, such timeuuid can be inputed as as date.
> However, two things seems non-optimal to me:
> * When one insert a timeuuid using a date format, we always pick *the* UUID corresponding
to this date with every other part of the UUID to 0. This kind of defeat the purpose of collision-free
timestamp and thus greatly limit the usefulness of the date syntax.
> * When cqlsh print timeuuid, it print them as date. But as thus, there is some information
lost which can be problematic (you can't update a specific column based on that return). In
a way, this is a cqlsh limitation, since cassandra return the UUID bytes. Yet, it also emphasis
somehow that from the point of using them, timeuuid are more UUID than really time.
> For the first point, it would make more sense that when inserting a date, we actually
pick a uuid with the corresponding timestamp *but* with the rest of the UUID being random.
It's not completely that simple because we don't want that randomness when the date are used
in a select query, but that's roughtly the same problem than CASSANDRA-4283 (and we can thus
use the same solution).
> The second point gives an idea. We could extends the date syntax to allow it to represent
uniquely a type 1 UUID. Typically, we could allow something like: '2012-06-06 12:03:00+0000
%a2fc07', where the part after the '%' character would be hexadecimal for the non-timestamp
part of the UUID. Understanding this syntax could allow to work with timeuuid uniquely with
meaningful date string which I think would be neat. But maybe that's a crazy idea, opinions?

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


View raw message