[jira] [Resolved] (CASSANDRA-4284) Improve timeuuid <-> date relationship

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-4284.
---------------------------------------

       Resolution: Later
    Fix Version/s:     (was: 1.2.0 beta 1)
         Assignee:     (was: Sylvain Lebresne)
    
> Improve timeuuid <-> date relationship
> --------------------------------------
>
>                 Key: CASSANDRA-4284
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4284
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.1.0
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql3
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira