为什么bson java实现使用4个字节的inc字段？ [英] Why the bson java implementation uses 4 bytes inc field?

问题描述

在BSON Java实现中，ObjectId由3个部分组成（源代码： 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 ）：

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代表字节）

这与文档中描述的内容有所不同（文档： http://docs.mongodb.org/manual/core/object-id/ ）

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.

如果您查看 BSON规范，您会看到旧驱动程序使用了一些UUID子类型，并且对互操作性进行了各种更改。例如，在 PYTHON-387 中提到支持旧式字节顺序和字节序

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.

根据 JAVA-337 计划在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字段？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！