You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2012/04/27 09:54:56 UTC
[jira] [Created] (CASSANDRA-4194) CQL3: improve experience with
time uuid
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
[jira] [Commented] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267279#comment-13267279 ]
Sylvain Lebresne commented on CASSANDRA-4194:
---------------------------------------------
bq. the "right" way to do this is either with a [sql standard] Interval data type
Agreed, I was a bit sloppy on that one.
Committed (2 first patches), thanks
> 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
[jira] [Commented] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268937#comment-13268937 ]
Sylvain Lebresne commented on CASSANDRA-4194:
---------------------------------------------
Oups, not sure what that line has to do with anything in the first place since we already lowercase for 'now'. Fixed in commit 72a90a9.
> 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
[jira] [Updated] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4194:
----------------------------------------
Attachment: 0003-Adds-x-days-ago-notation-for-convenience.txt
0002-Refactor-DateType-and-TimeUUIDType-to-share-code.txt
0001-Add-CQL3-timeuuid-type.txt
Adding 3 patches for this. The first one is the actual addition of timeuuid (btw, i'm fine if someone prefer some other name). The other two are related small improvement: the first one refactor the date parsing code to have it shared by both DateType and TimeUUIDType and the second one adds the parsing of things like '4 days ago' for convenience sake (I'm not claiming it's a super useful thing but I figured this could be nice for interactive sessions; I don't care too much about it though).
> 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
[jira] [Reopened] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans reopened CASSANDRA-4194:
-----------------------------------
commit e53d98 breaks RoundTripTest, specifically, this bit...
{noformat}
+ source = source.toLowerCase();
{noformat}
... as the lower-cased string no longer matches as ISO8601.
> 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
[jira] [Commented] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne resolved CASSANDRA-4194.
-----------------------------------------
Resolution: Fixed
> 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
[jira] [Commented] (CASSANDRA-4194) CQL3: improve experience with
time uuid
Posted by "paul cannon (JIRA)" <ji...@apache.org>.
[ 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