[
https://issues.apache.org/jira/browse/CASSANDRA-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4936:
----------------------------------------
Attachment: 4936.txt
Attaching a patch that implements what my previous comment describes.
A few precisions:
* the patch allows {{startOf('2012-11-07 18:18:22-0800')}} or even
{{startOf(12432343423)}} but not {{startOf(? )}}. It's just that it's simpler
to not support prepared marker for now. We can add it later, but I'd rather
leave it for later. It's not excessively useful anyway since any good library
will provide an equivalent to the {{startOf()}} method anyway (and so you can
use that client side for prepared statements).
* the patch change the fact that dates are accepted as valid TimeUUID
representation because, as arged previously, this is bogus. However, CQL2 has
done that bogus thing to, and I'm not sure it's worth fixing there as there
might be people relying on that buggy behavior. So the patch maintain the buggy
behavior fro CQL2.
* I talks about adding a 'random(date)' method for insertions sake in my
previous comment, but thinking about that a bit more, I'm not sure it's a good
idea. Namely, the only way to generate a version 1 UUID according to the spec
is based on the current time. Generating one from a timestamp is kind of not
safe. Now I admit that if you use the timestamp but randomize all other bits,
you probably end up with something having virtually no chance of collision, but
still, I'm slightly reluctant to do that in Cassandra. I'd rather let people do
that client side (and provide a UUID string) if they really want to. So instead
the patch only provides a {{now()}} method that generate a new unique timeuuid
based on the current time.
* The patch also adds the conversion for select statement I mention in my
previous comment. In fact it adds 2 methods {{dateOf()}} and
{{unixTimestampOf()}}. This part is kind of optional and I can rip it out if
there is objections (I meant to separate in 2 patches but scewed up and got
lazy). That being said, I kind of like it and with that I think we can just
have cqlsh stop printing timeUUID as dates (which the patch doesn't include
however).
Let's not shy away from the fact that this patch kinds of break backward
compatibility. I say "kinds of" because as I've said, I really think allowing
date litterals as timeuuid values is a bug so I really think this patch is a
bug fix. And if we get that in 1.2.1, I really don't think they'll be any arm
done. I also note that there isn't any way to fix this issue that don't "break
backward compatibility". So I'm really sorry I didn't got that fix up before
1.2.0, but I still really think we should do it nonetheless.
> Less than operator when comparing timeuuids behaves as less than equal.
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-4936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4936
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8.0
> Environment: Linux CentOS.
> Linux localhost.localdomain 2.6.18-308.16.1.el5 #1 SMP Tue Oct 2 22:01:37 EDT
> 2012 i686 i686 i386 GNU/Linux
> Reporter: Cesar Lopez-Nataren
> Fix For: 1.2.2
>
> Attachments: 4936.txt
>
>
> If we define the following column family using CQL3:
> CREATE TABLE useractivity (
> user_id int,
> activity_id 'TimeUUIDType',
> data text,
> PRIMARY KEY (user_id, activity_id)
> );
> Add some values to it.
> And then query it like:
> SELECT * FROM useractivity WHERE user_id = '3' AND activity_id < '2012-11-07
> 18:18:22-0800' ORDER BY activity_id DESC LIMIT 1;
> the record with timeuuid '2012-11-07 18:18:22-0800' returns in the results.
> According to the documentation, on CQL3 the '<' and '>' operators are strict,
> meaning not inclusive, so this seems to be a bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
