[SERVER-3153] The mongo shell needs better support for displaying and entering GUIDs/UUIDs Created: 26/May/11 Updated: 25/Oct/21 Resolved: 25/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 1.9.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Robert Stam | Assignee: | Geert Bosch |
| Resolution: | Duplicate | Votes: | 16 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Description |
|
Working with GUIDs in the mongo shell is painful. We need a better way to enter them. One suggestion, a factory method on BinData: > BinData.fromGuid("b4ebe978-bf69-489c-9d3e-bc6839d6de25") Or some other usable alternative. The shell should also use the same notation on output so that it is more readable. One final problem: all existing C# drivers have been writing GUIDs in a binary representation where the first three fields of the GUID are little endian (because that's what Guid.ToByteArray happens to return), whereas all other drivers are using the more sensible big endian representation. So depending on which driver stored the GUID the string representation would be different. This is a really difficult problem to solve without backward compatibility problems. The shell is affected because it needs to know what byte order to use when converting the string representation of a GUID to an instance of BinData. |
| Comments |
| Comment by Robert Stam [ 14/Jun/12 ] | |
|
Ryan, I agree. In the meantime I've attached a file of Javascript helper functions that could prove helpful to you. I wrote these to help me work with GUIDs in the mongo shell while working on the C# driver support for GUIDs. You can load these helper functions into the mongo shell by starting the mongo shell like this:
The uuidhelpers.js file has some brief comments at the top that illustrate how to use the helper functions. | |
| Comment by Ryan Hoffman [ 13/Jun/12 ] | |
|
This is a huge pain point for C# users. Currently there is no way to convert between the C# GUID data type and BinData(3, "") in the MongoDB shell. Additionally, all GUIDs show as BinData(3, "data"), which is an extremely inconvenient way to view GUIDs. It would be great if .NET GUIDs would be a first class citizen in the MongoDB shell. | |
| Comment by Robert Stam [ 29/Nov/11 ] | |
|
This JIRA is related to | |
| Comment by Robert Stam [ 29/Nov/11 ] | |
|
The implementation proposed in this JIRA issue is slightly at odds with that in An implementation of these methods as Javascript helper functions can be found at: https://github.com/mongodb/mongo-csharp-driver/blob/master/uuidhelpers.js which can be looked at as a reference. Don't know if this JIRA will be implemented in C++ code or in Javascript (in the latter case the uuidhelpers.js file will turn out to be even more useful). | |
| Comment by Jeffrey Yemin [ 17/Nov/11 ] | |
|
It would also be nice if you could set an option at global/db/collection level to tell it what UUID representation to assume. That way even subtype 3 binary data could be displayed as UUID("xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"). So something like livearcmdb02:PRIMARY> use authoring | |
| Comment by Robert Stam [ 09/Jul/11 ] | |
|
Proposed implementation: New global functions: UUID (creates a binary subtype 4 UUID using standard byte order) All 4 global functions should ignore any of these characters in the input string: " {", "-", "}" as they are commonly used in string representations of UUIDs. New methods attached to BinData prototype: toUUID (formats a binary subtype 4 UUID stored in standard byte order as a string) Changes to the shell: The shell should output binary subtype 4 values as: UUID("xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") The shell should output binary subtype 3 values as: HexData(3, "xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") (as opposed to JUUID, CSUUID or PYUUID because it doesn't know which byte order was used). |