Sylvain Lebresne created CASSANDRA-4194:
-------------------------------------------

             Summary: CQL3: improve experience with time uuid
                 Key: CASSANDRA-4194
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4194
             Project: Cassandra
          Issue Type: Improvement
          Components: API
            Reporter: Sylvain Lebresne
            Assignee: Sylvain Lebresne
            Priority: Minor
             Fix For: 1.1.1


This ticket proposes to add a timeuuid type to CQL3. I know that the uuid type 
does support version 1 UUID (which is fine), but my rational is that time 
series is a very common use case for Cassandra. But when modeling time series, 
it seems to me that you'd almost always want to use time uuids rather than 
timestamps to avoid having to care about collision. In those case, using a 
timeuuid type would imo have the following advantages over simply uuid:
# the type convey the idea that this is really a date (but need to avoid 
collision). In other words, the 'time' in timeuuid has a documentation purpose.
# it validates that you do only insert a UUID v1. Inserting non-time based UUID 
when you really care about the time ordering is a important mistake, it's nice 
to validate this doesn't happen (it's one of the goal of the type after all)
# it'll allow to parse date values (which TimeUUIDType already does). Since 
timeuuid is really a date, it's useful and convenient to allow '2012-04-27 
11:32:02' as a value.

I'll note that imho there really is no reason not to at least allow 3) and even 
if there is strong opposition to adding a new timeuuid type (though I don't see 
why that would be a big deal) we could add the parsing of date to uuid. But I 
do think personally that 1) and 2) are equally important and warrant the 
addition of timeuuid (and it'll feel less random to parse date as timeuuid than 
to do it for uuid).


--
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

        

Reply via email to