cqlsh和python cassandra驱动程序中最大时间uuid的差异

w8f9ii69  于 2021-06-10  发布在  Cassandra
关注(0)|答案(1)|浏览(659)

我的python代码在cassandra中找不到记录,这似乎归结为cqlsh中的mintimeuuid/maxtimeuid函数与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

我不明白他们怎么会不一样,有什么想法吗?我在python3.5.2而不是上面的2.7中尝试了同样的方法,得到了同样的结果。

pbgvytdp

pbgvytdp1#

cassandra timeuuid compare使用(有符号)8位整数比较uuid的最低有效位。大多数有效位使用内存顺序(无符号整数比较)。因此,min/maxtimeuid函数根据cassandra比较顺序创建最小/最大的uuid。
我的猜测是,无论是谁编写了原始代码,都不知道有符号字节和无符号字节比较之间的区别,然后必须遵守遗留顺序,以避免破坏任何现有数据。
您可以查看此提交以了解更多详细信息:https://github.com/apache/cassandra/commit/6d266253a5bdaf3a25eef14e54deb56aba9b2944

相关问题