[
https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14311947#comment-14311947
]
Sylvain Lebresne commented on CASSANDRA-8730:
---------------------------------------------
bq. It looks to me like TimeUUID had the behaviour downgraded to CQL2 only,
whereas UUID has not.
The code inconsistency is likely just a historical accident, but it kind of
doesn't matter much since {{fromString}} will never be called by CQL3 (on a
date-string) as CQL3 only accepts UUID literals for UUID (not string literals,
contrarily to CQL2). So as long as we preserve the behavior for CQL2 until 3.0,
we can make the {{fromString}} implementations consistent by either accepting
or rejecting dates in both case (I'd personally go with rejecting dates as it's
dangerous in the first place, but I don't care enough to argument more than
that if someone disagree).
bq. makes TimeUUIDType extend UUIDType
While I don't mind the extension per-se, we have to be careful on the
comparison because unfortunately, TimeUUIDType does *not* compare as UUIDType
does. That is, after having compared the timestamps, UUIDType perform an
unsigned comparison of the lsb, while TimeUUIDType uses
[ByteBuffer.compareTo|http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compareTo(java.nio.ByteBuffer)]
which does a byte-signed comparison. Before someone asks, there is no good
excuse for doing so, it's a pretty old "mistake", but it's not something we can
afford to break now.
As an aside, I personally think this should be targeted at 3.0 (it's not a bug
fix). Also, as even subtly changing the comparison would have desastrous
consequence, it would be nice to add a few tests that checks that old and new
versions compare the same way (we can't be exhaustive, but we can get a fair
coverage of all code path easily enough).
> Optimize UUIDType comparisons
> -----------------------------
>
> Key: CASSANDRA-8730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8730
> Project: Cassandra
> Issue Type: Improvement
> Reporter: J.B. Langston
> Assignee: Benedict
> Fix For: 2.1.4
>
>
> Compaction is slow on tables using compound keys containing UUIDs due to
> being CPU bound by key comparison. [~benedict] said he sees some easy
> optimizations that could be made for UUID comparison.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
