cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Hobbs <>
Subject TimeUUIDType Comparison
Date Mon, 16 Apr 2012 16:47:57 GMT
I just discovered an issue with how TimeUUIDs are compared in Cassandra
that was affecting pycassa and probably affects other clients.

To allow for easy slicing of rows with TimeUUIDType comparators, pycassa
lets you supply a timestamp for the column start and end.  To make sure
that all columns within that time range were collected, regardless of the
random portions of the UUIDs, I was filling the non-timestamp bytes with
0x00 bytes or 0xff bytes to make the lowest or highest possible TimeUUID,
respectively, with the same timestamp.

It turns out that the comparison that Cassandra does to break ties when the
timestamp components match performs a signed byte comparison on each byte.
This means 0x00 is not the lowest possible value, 0x80 is.  Likewise, 0x7f
is the actual highest byte value, not 0xff.

So, if your client does something similar, this commit may be a useful
reference for you in order to get the correct behavior:

Tyler Hobbs
DataStax <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message