Detailed analysis of GUID display issues in Mongodb

Find the problem

I recently migrated the storage of a program to Mongodb and discovered a phenomenon: after the Guid type is written, the data read in the program is different from the data displayed by the client tool. A simple example is as follows:

 var doc = new {_id = 1, Value = Guid.Parse("{B63932BB-9688-432B-B3A0-C4AE3FD2696A}") };
 collection.InsertOne(doc.ToBsonDocument());

After writing to the DB, we view it from the client tool:

By comparison, we can find that the displayed value is different from the written form, but the read value is correct. The answer to this question can be found in the official documentation specification:

Official documentation: http://bsonspec.org/spec.html

Mongodb stores uuid as a binary type, and uses a subtype to mark its type as uuid. In the drivers provided for C#, Java, and Python, the subtype is mapped to 3 (Legacy UUID) by default, which is also displayed in the client tool:

In fact, most client tools can also support displaying the Legacy UUID as we wrote it.

Workaround

Although this does not affect the functionality of the program, it often affects our debugging of the program because the string we see at first glance is not in the format in which it was written. A better solution is to store in standard UUID format by default. You only need to set a global configuration:

 BsonDefaults.GuidRepresentation = GuidRepresentation.Standard;

This is much more convenient:

Reference articles:

MongoDB Best Practices for UUID Data

Summarize

The above is the detailed content about the display problem of GUID in Mongodb. For more information about the display problem of GUID in Mongodb, please pay attention to other related articles on 123WORDPRESS.COM!