[SERVER-1201] shell support for UUID (binary subtype 3) Created: 08/Jun/10 Updated: 14/Apr/16 Resolved: 15/Jan/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Jørn Wildt | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Duplicate | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Any |
||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Native support for GUID's would be nice. Right now ObjectId's are the only (native) way to manage unique identifiers. But in some projects ot may not be possible to use ObjectId's - either due to legacy code or other constrains. My pet reason for not using ObjectId's is that they leak persistency concerns into my domain entities. By using GUID's I avoid making the code dependent directly on a class defined by MongoDB (using the Norm C# driver). It is possible to use GUID's but they are stored as binary blobs and as such one cannot read and use the values through the shell while debugging. |
| Comments |
| Comment by Caleb Jones [ 14/Jan/13 ] |
|
This is causing us some pain as we switched our UUIDs over to use BinData() from string values when our tests showed a 15-25% improvement in index size as collection sizes approached 10 million documents. It becomes a pain when trying to poke around in the MongoShell when all we see back is BinData(3,"BASE64"). |
| Comment by Victor Boivie [ 28/Jul/11 ] |
|
I have made a github pull request at https://github.com/mongodb/mongo/pull/72 that at least displays the uuid bindata better. |
| Comment by Eliot Horowitz (Inactive) [ 09/May/11 ] |
|
Is there a clean commit that adds the needed code? |
| Comment by Daris A Nevil [ 09/May/11 ] |
|
I would be happy to split out the UUID-specific code in order to push it into the main branch. |
| Comment by Sam Kass [ 27/Apr/11 ] |
|
Any chance the UUID-specific shell stuff could get accepted into the next Mongo baseline version? UUID handling is currently awful in the shell and it's a relatively widely-used data type... |
| Comment by Daris A Nevil [ 27/Apr/11 ] |
|
Sam, thanks for the kind words, glad this modification will be useful to others. Actually, the implementation for UUID representation in BSON already existed in MongoDB 1.7. I simply modified the shell to make it easy to use. The only types I added were the IP Address and MAC Address types. |
| Comment by Sam Kass [ 07/Apr/11 ] |
|
Daris, the UUID change seems especially valuable since "new UUID" in the shell often does not do what is expected... saving one in an object via the CLI will not actually save the data, nor auto-translate it into a BinData(3, "- It would be awfully nice if UUID was just a synonym for BinData type 3 in the shell, with the underlying representation staying how it is in Mongo 1.8, IMHO. If all BinData type 3's could display as UUID objects within the shell, and all UUID's entered were stored as BinData type 3's, it would work seamlessly with existing mappings. Also a consideration, though, is least-significant-byte vs. most-significant-byte ordering, as well as least-significant-longword vs most-significant-longword when displaying the hex values of UUIDs. |
| Comment by Daris A Nevil [ 28/Mar/11 ] |
|
I've created a branch that makes the UUID() type a native type of the javascript mongodb shell. See http://jira.mongodb.org/browse/SERVER-2413. I've done the same for the PHP driver, see https://github.com/redmeadowman/mongo-php-driver. |
| Comment by Justin Dearing [ 11/Jun/10 ] |
|
We've been discussing uuid support on the dev list: |
| Comment by auto [ 09/Jun/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Jørn Wildt [ 08/Jun/10 ] |
|
Now that I see that MongoDB have different binary subtypes, I think the request should be extended to all those (known) subtypes. MD5 should be displayable too. All of this could even be solved if binary values with less than X bytes were shown as hex. Just brainstorming ... |