[
https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411307#comment-13411307
]
Sylvain Lebresne commented on CASSANDRA-4284:
---------------------------------------------
Having though more about this issue, I'm afraid it might not be that simple.
Picking a random 'clock and sequence' part when converting a time to a TimeUUID
would work well for insertions, but wouldn't for queries. Typically a query
like "SELECT ... WHERE uuid >= '2012-06-06 12:03:00+0000' and uuid <
'2012-06-06 12:03:03+0000'" would potentially miss some rows if we timeuuid
generated from those two dates has some random part.
Note that this doesn't change the fact that imho our currently timeuuid/data
relationship is confusing, as "proved" by the following comment
http://www.datastax.com/dev/blog/cql3-evolutions#comment-80758.
I'll also remark that if we were to extend the date syntax, this could help the
problem above, since we would use something like '2012-06-06 12:03:00+0000 %%'
where the '%%' would mean 'generate a random part for the rest of the
timeuuid'. But I see this data extension doesn't gather much enthusiasm.
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.
bq. sounds messy wrt the general to/from string api in AbstractType
Can you elaborate on that argument? (I'm not sure I see why it would mess with
the to/from string api particularly)
> 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
