Sylvain Lebresne created CASSANDRA-4284:
-------------------------------------------
Summary: 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
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
