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 Wed, 11 Jul 2012 18:49:41 GMT


paul cannon commented on CASSANDRA-4284:

bq. But if we don't do anything here, I would be of the opinion of making cqlsh stop interpreting
timeuuid as date by default because I'm afraid it will confuse more people than it will help.

I'd much rather have the % syntax addition than to do this. It seems like people using timeuuid
will "usually" want to see the date value associated with their timeuuids, not the actual
uuid value. They can still get the latter with an ASSUME, but I think that would be the exception,
not the rule. We might just need to make that particular use of ASSUME more easily found (maybe
put it in the CQL3 docs along with the description of timeuuid).

What if we (a) filled in random bits for the MAC address area of the uuids, and (b) extended
the recognized timestamp syntax to allow specifying fractional seconds? We have 7 extra digits
of precision that we could be allowing users to employ. It's lots more obvious what the extra
digits mean when printed, and people can understand easily how their values will sort with
respect to other timeuuids. If a user inserts multiple timestamps with the exact same value
(down to the 100-ns precision), then they will end up being sorted randomly with respect to
each other, but the user should have no expectations about their ordering, so that's ok. Of
course if the user wants to specify the entire value of the uuid, she can use the uuid syntax.
> 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