[
https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266737#comment-13266737
]
Jonathan Ellis commented on CASSANDRA-4194:
-------------------------------------------
+1 on patches 1 and 2.
i'm +1 on adding conveniences like the one in patch 3, but -1 on this
implementation. i don't want to maintain a bunch of ad-hoc conversions. (what
is special about days? why not seconds/minutes/hours/months/years?)
the "right" way to do this is either with a [sql standard] Interval data type,
or with a function. (Or both: a function that takes an interval, and applies
it to now() to give a datetime.)
that's way out of scope for now though. so i'd rather just leave it out.
> 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
