问题描述
在BSON Java实现中,ObjectId由3个部分组成(源代码:):
In BSON Java implementation, an ObjectId is composed by 3 pieces (source code: http://grepcode.com/file/repo1.maven.org/maven2/org.mongodb/mongo-java-driver/2.9.0/org/bson/types/ObjectId.java#ObjectId.%3Cinit%3E%28int%2Cint%2Cint%29 ):
XXXX XXXX XXXX
-------------------------
time machine&pid inc
(每个X代表字节)
这与文档中描述的内容有所不同(文档:)
this is a bit different from what's described in document (doc: http://docs.mongodb.org/manual/core/object-id/ )
XXXX XXX XX XXX
--------------------------
time machine pid inc
(每个X代表一个字节)
有人可以告诉我为什么Java驱动程序不遵循规范吗?
谢谢!
推荐答案
我希望ObjectID的初衷是生成合理唯一的主键,而不是打包驱动程序随后将开始将其解析为数据的字段。
I expect the original intent of an ObjectID was to generate a reasonably unique primary key, rather than packing fields that drivers would then start parsing as data.
随着MongoDB生态系统的发展,一些开发人员发现将多个驱动程序的ObjectID解释为:以及确保生成的ID的一致性。
As the MongoDB ecosystem has evolved, some developers have found it useful to interpret the ObjectID from multiple drivers as well as ensure consistency of generated IDs.
如果您查看,您会看到旧驱动程序使用了一些UUID子类型,并且对互操作性进行了各种更改。例如,在中提到支持旧式字节顺序和字节序
If you look at the BSON spec you will see there are a few subtypes for UUID used by older drivers, and various changes for interoperability. For example, there is mention on PYTHON-387 of supporting "legacy" byte orders and endianness for the C# and Java drivers.
根据计划在3.0 Java驱动程序版本中解决Java驱动程序的ObjectID不一致问题。
As per JAVA-337 in the MongoDB issue tracker, the Java driver's ObjectID inconsistency is planned to be addressed in the 3.0 Java driver release.
这篇关于为什么bson java实现使用4个字节的inc字段?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!