[
https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283746#comment-13283746
]
Jonathan Ellis commented on CASSANDRA-4284:
-------------------------------------------
bq. 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
+1
bq. 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
+0, sounds messy wrt the general to/from string api in AbstractType.
> 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
