You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Eriksson (Jira)" <ji...@apache.org> on 2019/11/11 13:14:00 UTC

[jira] [Updated] (CASSANDRA-15064) Wrong ordering for timeuuid fields

     [ https://issues.apache.org/jira/browse/CASSANDRA-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Eriksson updated CASSANDRA-15064:
----------------------------------------
     Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Implementation(12988)
       Complexity: Normal
    Discovered By: User Report
           Status: Open  (was: Triage Needed)

[~jmeredithco] anything more to do here?

> Wrong ordering for timeuuid fields
> ----------------------------------
>
>                 Key: CASSANDRA-15064
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15064
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Cluster/Schema
>            Reporter: Andreas Andersen
>            Assignee: Jon Meredith
>            Priority: Normal
>         Attachments: example.cql
>
>
> Hi!
> We're seeing some strange behavior for the ordering of timeuuid fields. They seem to be sorted in the wrong order when the clock_seq_low field in a timeuuid goes from 7f to 80. Consider the following example:
> {noformat}
> cqlsh:test> show version; 
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4] 
> cqlsh:test> CREATE TABLE t ( 
>         ...     partition   int, 
>         ...     t           timeuuid, 
>         ...     i           int, 
>         ...  
>         ...     PRIMARY KEY(partition, t) 
>         ... ) 
>         ... WITH CLUSTERING ORDER BY(t ASC); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5); 
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC; 
>  
>  partition | t                                    | i 
> -----------+--------------------------------------+--- 
>          1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3 
>          1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4 
>          1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5 
>          1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1 
>          1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2 
>  
> (5 rows) 
> cqlsh:test>
> {noformat}
> The expected behavior is that the rows are returned in the same order as they were inserted (we inserted them with their clustering key in an ascending order). Instead, the order "wraps" in the middle.
> This issue only arises when the 9th octet (clock_seq_low) in the uuid goes from 7f to 80. A guess would be that the comparison is implemented as a signed integer instead of an unsigned integer, as 0x7f = 127 and 0x80 = -128. According to the RFC, the field should be treated as an unsigned integer: [https://tools.ietf.org/html/rfc4122#section-4.1.2]
> Changing the field from a timeuuid to a uuid gives the expected correct behavior:
> {noformat}
> cqlsh:test> CREATE TABLE t ( 
>         ...     partition   int, 
>         ...     t           uuid, 
>         ...     i           int, 
>         ...  
>         ...     PRIMARY KEY(partition, t) 
>         ... ) 
>         ... WITH CLUSTERING ORDER BY(t ASC); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4); 
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1, 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5); 
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC; 
>  
>  partition | t                                    | i 
> -----------+--------------------------------------+--- 
>          1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1 
>          1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2 
>          1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3 
>          1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4 
>          1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5 
>  
> (5 rows) 
> cqlsh:test>{noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org