Querying for UUID

[nilskp]

Is there an easy/recommended way to do this from the shell? Alternatively, can someone list the steps needed to turn a UUID into a Binary type 3 string I can query for?

[Stephen Steneker]

Is there an easy/recommended way to do this from the shell? Alternatively, can someone list the steps needed to turn a UUID into a Binary type 3 string I can query for?

Hi,

The shell in MongoDB 2.0+ has a UUID() helper:

> db.uuid.insert({'myid': UUID('aaaabbbbccccddddeeeeffff00001111')})

> db.uuid.find({'myid': UUID('aaaabbbbccccddddeeeeffff00001111')})

{

"_id" : ObjectId("5087caf7db725618a2937d61"),

"myid" : BinData(3,"qqq7u8zM3d3u7v//AAAREQ==")

}

You can run `help misc` in the shell for more info on UUID/BinData helper functions.

Cheers,

Stephen

[Nils Kilden-Pedersen]

Excellent, I'll try that. Thanks!

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[nilskp]

Just tried it, but unfortunately it doesn't match what I'm seeing in MongoVUE. Not sure why.

[Stephen Steneker]

Just tried it, but unfortunately it doesn't match what I'm seeing in MongoVUE. Not sure why.

Hi,

Perhaps the UUID isn't in the expected format.

Can you include an example of what you see in MongoVUE ?  You could also try finding a document in the shell by some other property (to check what the actual stored UUID value is).

Cheers,

Stephen

[nilskp]

This UUID, "a00a88b4-ab49-4106-9904-b84f506a6628" when converted by a standard base64 converter, gives me "oAqItKtJQQaZBLhPUGpmKA==", which is identical to what mongo's UUID shell function gives me. However that document in MongoVUE, with "Show Binary type 3 values as Guid" enabled, shows it as "ab494106-88b4-a00a-2866-6a504fb80499" (which is "q0lBBoi0oAooZmpQT7gEmQ==" in base64), and yet shows it as BinData(3, "BkFJq7SICqAoZmpQT7gEmQ==") in the text view.

So I have to conclude that Binary display in MongoVUE is completely broken.

[Robert Stam]

There are issues with byte orders where GUIDs are concerned. Unfortunately, different drivers have stored GUIDs using different byte orders historically. This was of course accidental and not by design.

Can you let us know which driver(s) you used to store the documents with?

--

[nilskp]

On Wednesday, October 24, 2012 9:08:54 AM UTC-5, Robert Stam wrote:

There are issues with byte orders where GUIDs are concerned. Unfortunately, different drivers have stored GUIDs using different byte orders historically. This was of course accidental and not by design.

Can you let us know which driver(s) you used to store the documents with?

I'll drop the database and repopulate with the lates 2.9.2 Java driver, and report back. But I think MongoVUE is no longer being updated, so there's not much hope on that end.
 

[nilskp]

Using the latest Java 2.9.2 driver and MongoDB 2.2, the UUID function is not compatible. E.g.

Same document:

Java:
"_id" : { "$uuid" : "0bce877f-7591-40fd-adae-51b9de9b635a"}

vs

Shell
"_id" : BinData(3,"/UCRdX+HzgtaY5veuVGurQ==")

Converting in shell:

> UUID("0bce877f759140fdadae51b9de9b635a")
BinData(3,"C86Hf3WRQP2trlG53ptjWg==")

[Bernie Hackett]

The Java driver stores UUIDs in a non-standard byte order. There is a
ticket to correct this here:

https://jira.mongodb.org/browse/JAVA-403

[nilskp]

Thanks.

Stunning how that ticket was raised in July and doesn't appear to have any fix in the immediate future (says 3.0).

[nilskp]

On Wednesday, October 24, 2012 9:50:30 AM UTC-5, nilskp wrote:

Thanks.

Stunning how that ticket was raised in July and doesn't appear to have any fix in the immediate future (says 3.0).

Oh dear, just noticed it was July 2011. So this issue has been known for well over a year with no fix.

I'm in the early phases of a development project with Mongo, at right now I'm seriously considering finding something else. I'm practically speechless at how cavalier this issue appears to be taken.

 

[Bernie Hackett]

I believe the problem is that fixing this issue in the Java driver
would be a backward breaking change for a lot of users. The only two
other drivers that support a built in UUID/GUID type (PyMongo/C#) both
support the Java byte order if you are round tripping documents
between multiple languages.

[nilskp]

I don't see why. The new, correct, encoding would use subtype 4 instead of the current subtype 3, while maintaining current decoding behavior for subtype 3.