[
https://issues.apache.org/jira/browse/CASSANDRA-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412546#comment-13412546
]
Sylvain Lebresne commented on CASSANDRA-4284:
---------------------------------------------
bq. It seems like people using timeuuid will "usually" want to see the date
value associated with their timeuuids
I definitively agree on the principle that timeuuid are more dates than they
are uuid, at least in the intention. However, using only the date as the
representation means that it's not really a representation but an estimate.
Concretely, it means that for newcomers:
* it will look like timeuuid breaks the PK constraint (that's just a illusion
of the imprecise representation but still confusing)
* if someone do a read, and reuse what you get to update the row, you won't
modify what you'd expected to modify. I think that one is a big catch because
it makes it easy to corrupt the DB (it's easy to forget the representation is
not precise even if you know it).
All this make me worried that showing just the date par by default will be more
confusing than helpful.
bq. I'd much rather have the % syntax addition than to do this
For the reasons above (timeuuid are fundamentally dates, but dates without
syntax extension is dangerous) I think I would prefer that too.
bq. (a) filled in random bits for the MAC address area of the uuids
Don't that have the problem I described above for queries? I.e. if you
introduce random by default in the translation of dates to timeuuid, the same
request executed twice could return different results.
bq. (b) extended the recognized timestamp syntax to allow specifying fractional
seconds?
I'm not sure I follow, could you give an example.
> 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
