cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jefferson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13462) Unexpected behaviour with range queries on UUIDs
Date Thu, 20 Apr 2017 07:57:04 GMT


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:
>             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

View raw message