cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4194) CQL3: improve experience with time uuid
Date Tue, 01 May 2012 03:56:04 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265622#comment-13265622
] 

paul cannon commented on CASSANDRA-4194:
----------------------------------------

Oh, this is great. I've been wanting to add this for a while. +1 on the idea (not a review).
                
> 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
>              Labels: cql3
>             Fix For: 1.1.1
>
>         Attachments: 0001-Add-CQL3-timeuuid-type.txt, 0002-Refactor-DateType-and-TimeUUIDType-to-share-code.txt,
0003-Adds-x-days-ago-notation-for-convenience.txt
>
>
> 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

        

Mime
View raw message