TL; DR: DocumentDB自动生成的ID应该是GUID还是UUID,实际上有区别吗?如果它们是UUID,那么UUID的哪个变体/版本?
后台:如果您没有提供ID,某些DocumentDB客户端库会自动为您生成ID。我在Azure blog和several related questions中看到过,生成的ID是GUID。我知道some discussion是GUIDs是UUIDs还是UUID RFC,很多人都说他们是d981befd-d19b-ee48-35bd-c1b507d3ec4f
。
问题:但是,我注意到DocumentDB自动生成的一些ID不遵循DocumentDB Studio,只允许“版本中的数字1-5” “唠叨(V
中的xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx
}。 DocumentDB生成包含该半字节中任何十六进制数字的ID,例如Azure portal,其版本半字节是e
的第一个ee48
。
这可能取决于用于创建文档的客户端。在我们的DocumentDB数据库中,我们拥有第三个分组dde5
,627a
,fe95
等文档。通过使用选项Collection.createDocument()
调用{'disableAutomaticIdGeneration': false}
,可以在存储过程中存储这些文档。我通过第三方{{3}}应用程序创建的其他文档在第三个分组中始终具有4xxx
,这是一个有效的UUID版本。但是,我通过{{3}}创建的文档包含非标准的第三组,例如b359
。
问题:自动生成的DocumentDB ID应该是GUID还是UUID,实际上有区别吗?如果是UUID,那么哪个变种?
答案 0 :(得分:6)
在GitHub上的源代码中,我发现各种客户端和服务器端库使用几种不同的方法来创建他们称之为GUID(在某些库中)或UUID(在其他库中)的内容。 / p>
nodejs客户端Javascript client和server-side library通过连接一系列十六进制数字和连字符来制作他们称之为GUID的内容。请注意,这些是随机的,但不符合创建RFC4122版本4 UUID的规则。
Python client和Java client调用各自的标准library methods来生成随机(版本4)UUID。
.NET客户端可通过NuGet获得,但source code尚未发布。
摘要: