I really think the bug here is that TimeUUIDType.fromString() accepts a date as input. But a date is not a valid representation of a timeuuid, and the fromString method does arbitrarily pick some 0's for parts of the resulting UUID.
In other words, the SELECT query above should be invalid.
Now don't get me wrong, selecting timeuuid based on dates is useful but that is a slightly different problem. So what I think we should do is:
- refuse dates as valid timeuuid values because they just are not.
- add convenience methods to translate dates to precise timeuuid. For querying we would have 'startOf()' and 'endOf()' (where 'startOf(<date> )' (resp. 'endOf(<date> )') would return the smallest (resp. biggest) possible timeuuid at time <date> ). And for insertion we could optionally add 'random(<date> )' that would return a random timeuuid at time '<date>' (we could even accept 'now' as syntactic sugar for 'random(now)' if we feel like it).
That would also mean that cqlsh should stop this non-sense of displaying timeuuid like date. Again, I understand the intention of making it more readable but this will confuse generations of CQL3 users. I do am in favor of finding a non confusing way to make it readable for users. In fact one solution could be to handle that on the CQL side and to allow 'SELECT dateOf(x ) FROM ...' that would return a date string from timeuuid x (but now it's clear, you've explicitly asked for a lossy representation of x).
I note that this suggestion pretty much fixes the problem discussed in
I note that Tyler's solution of basically automatically generating the startOf() and endOf() method under the cover based on whether we've use an inclusive of exclusive operation may appear seductive but I don't think we should do that because:
- if you do that, what about SELECT ... WHERE activity_id = '2012-11-07 18:18:22-0800'. You still have no solution for that and by doing magic under the carpet for < and >, you've in fact blurred what = really does.
- "it would just require passing along information about whether to create the highest or lowest TimeUUID representation for a given datestamp based on the comparison operator that's used" <- while this seem simple on principle, this will yield very very ugly special cases internally. This is not 2 lines of code.
- more generally, this doesn't solve the fact that date are not valid representation of timeuuid. For example, I still think the first point mentioned in
CASSANDRA-4284 is a bug in its own right.
Allowing dates as valid representation of timeuuid is a bug, let's fix it.