Различия для максимального времени uuid в cqlsh и Python cassandra driver

У меня ошибка, из-за которой мой код python не может найти запись в Cassandra, и, похоже, это сводится к различиям в функциях minTimeuuid / maxTimeuuid в cqlsh по сравнению с драйвером python.

Когда я запускаю запрос в cqlsh (столбец ts - это TimeUUID):

cqlsh:mydb> SELECT minTimeuuid(unixTimestampOf(ts)), maxTimeuuid(unixTimestampOf(ts)), unixTimestampOf(ts), dateOf(ts) from mytable where ...;

 minTimeuuid(unixTimestampOf(ts))     | maxTimeuuid(unixTimestampOf(ts))     | unixTimestampOf(ts) | dateOf(ts)
--------------------------------------+--------------------------------------+---------------------
 177dc170-b8e3-11e1-8080-808080808080 | 177de87f-b8e3-11e1-7f7f-7f7f7f7f7f7f |       1339982128903 | 2012-06-18 03:15:28+0200

Когда я запускаю то же самое в Python:

Python 2.7.12 (default, Oct  8 2019, 14:14:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cassandra.util
>>> from datetime import datetime
>>> dt = datetime(2012,6,18,1,15,28,903000)
>>> cassandra.util.max_uuid_from_time(dt)
UUID('177dc170-b8e3-11e1-bf7f-7f7f7f7f7f7f')
>>> cassandra.util.min_uuid_from_time(dt)
UUID('177dc170-b8e3-11e1-8080-808080808080')

Обратите внимание, что минимальные версии идентичны, но максимальное время uuid - нет:

Min (cqlsh first):                    |  Max (cqlsh first):
177dc170-b8e3-11e1-8080-808080808080  |  177de87f-b8e3-11e1-7f7f-7f7f7f7f7f7f
177dc170-b8e3-11e1-8080-808080808080  |  177dc170-b8e3-11e1-bf7f-7f7f7f7f7f7f

Не понимаю, как они могут быть разными, есть идеи? Я пробовал то же самое в Python 3.5.2, а не в 2.7, как указано выше, с теми же результатами.


person schoel    schedule 07.01.2020    source источник


Ответы (1)


Cassandra timeuuid compare использует (подписанное) 8-битное целочисленное сравнение для младших битов UUID. Наиболее значимые биты используют порядок памяти (сравнение беззнаковых int). Таким образом, функции min / maxTimeuuid создают UUID, который будет наименьшим / наибольшим в соответствии с порядком сравнения Cassandra.

Я предполагаю, что тот, кто написал исходный код, игнорировал разницу между сравнением подписанных и беззнаковых байтов, и тогда просто нужно было соблюдать устаревший порядок, чтобы не повредить существующие данные.

Вы можете проверить этот коммит для получения дополнительных сведений: https://github.com/apache/cassandra/commit/6d266253a5bdaf3a25eef14e54deb56aba9b2944

person Kostja    schedule 01.12.2020