[
https://issues.apache.org/jira/browse/CASSANDRA-13462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976267#comment-15976267
]
Andrew Jefferson commented on CASSANDRA-13462:
----------------------------------------------
Thanks for the response. I understand that this won't change because of the way
the clustering relates to sorting on disk. I'm aware that sorting of timeuuids
is important.
Because timeuuid and uuid are documented as different types and can be
specified explicitly on a column I had thought that the time-based sorting
would only apply if I did:
```
CREATE TABLE time_sorted (
pk int PRIMARY KEY,
ck timeuuid,
val int
);
```
I had hoped that this would not force time-uuid style comparison:
```
CREATE TABLE if_only_it_were_value_sorted (
pk int PRIMARY KEY,
ck uuid,
val int
);
```
> Unexpected behaviour with range queries on UUIDs
> ------------------------------------------------
>
> Key: CASSANDRA-13462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13462
> Project: Cassandra
> Issue Type: Bug
> Reporter: Andrew Jefferson
>
> My expectation is that UUIDs should behave as 128 bit integers for comparison.
> However it seems that the Cassandra implementation compares first the uuid
> version number, then the remaining values of the uuid.
> e.g. in C*
> 10000000-0000-3000-0000-000000000000
> is greater than
> 20000000-0000-1000-0000-000000000000
> (n.b. the 13th value is the uuid version)
> - this is consistent across range queries and using ORDER BY
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
