[
https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412912#comment-13412912
]
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.:
{noformat}
2012-07-12 15:11:19+0000
{noformat}
), we could extend it to allow things like
{noformat}
2012-07-12 15:11:19.8810219+0000
{noformat}
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:
{noformat}
2012-07-12 15:11:19.8810219+0000 %2d826ed5b67249fc
{noformat}
..uniquely specifies UUID {{d5b7b46b-cc33-11e1-ad82-6ed5b67249fc}}.
> 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
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
