-
Notifications
You must be signed in to change notification settings - Fork 133
Description
timeuuid
is a UUID v1 - it contains a timestamp and some random bits that together form a unique identifier.
Their comparison operator should compare them primarily based on this timestamp.
timeuuid
values are currently represented using uuid::Uuid
, but the comparison operators of uuid::Uuid
don't compare timeuuid
values in the same way that Cassandra/Scylla does.
For example, with values 00000257-0efc-11ee-9547-00006490e9a6
and fed35080-0efb-11ee-a1ca-00006490e9a4
:
Cassandra believes that fed35080-0efb-11ee-a1ca-00006490e9a4
is smaller:
CREATE KEYSPACE ks WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor': 1};
CREATE TABLE ks.tab (p int, c timeuuid, PRIMARY KEY (p, c));
INSERT INTO ks.tab (p, c) VALUES (0, 00000257-0efc-11ee-9547-00006490e9a6);
INSERT INTO ks.tab (p, c) VALUES (0, fed35080-0efb-11ee-a1ca-00006490e9a4);
SELECT p, c FROM ks.tab;
p | c
---+--------------------------------------
0 | fed35080-0efb-11ee-a1ca-00006490e9a4
0 | 00000257-0efc-11ee-9547-00006490e9a6
(2 rows)
Because it has a lower timestamp value:
timeuuid_col | system.totimestamp(timeuuid_col)
--------------------------------------+----------------------------------
fed35080-0efb-11ee-a1ca-00006490e9a4 | 2023-06-19 23:49:56.990000+0000
00000257-0efc-11ee-9547-00006490e9a6 | 2023-06-19 23:49:58.961000+0000
But Uuid
comparison says the opposite, as it compares the bytes in lexicographical order:
let mut vals = [
uuid::uuid!("fed35080-0efb-11ee-a1ca-00006490e9a4"),
uuid::uuid!("00000257-0efc-11ee-9547-00006490e9a6"),
];
vals.sort();
dbg!(vals);
// Prints:
vals = [
000002570efc11ee954700006490e9a6,
fed350800efb11eea1ca00006490e9a4,
]
It would be useful to have a struct that represents timeuuid
values and has the same semantics as the values in Cassandra.
See the discussion in python driver for further explanation and sample python code: scylladb/python-driver#231