[Document view] : Need to correctly handle ObjectID-like data when specified in nested fields

Courtesy @Danlock for pointing this out. Pasting comment below:

Prior discussion here

Related to this issue, nested objectId are not set as object ids properly, in the case of:

{
  "_id": "5aa0150e1430142dda49b551",
  "createdAt": "2018-03-07T16:36:30.436Z",
  "data": {
    "Quasi": "8590406b-67fa-4e08-819d-2860f5fdca79"
  },
  "name": "g6d-car",
  "sensors": [
    {
      "_id": "5adf3b43194dd500010542ea",
      "createdAt": "2018-04-24T14:12:19.693Z",
      "type": "camera"
    }
  ],
  "type": "car",
  "updatedAt": "2018-04-24T14:12:19.693Z"
}

If I make any changes the inner sensor ids will be overwritten with “5adf3b43194dd500010542ea” instead of ObjectId(“5adf3b43194dd500010542ea”).

I can make another issue if you want, but this seems relevant.

[PrashanthCorp]

I have a basic test for arrays under the relatedTo property.

From my understanding, UUID is part of the binary data type, of sub-type 3 or 4 here and in the spec - under non-terminals.

For testing that the constructed UUID remains consistent, I used the mongo shell to create a UUID(with a 32 digit hex seed), insert that in a document, and verify that the uuid property (24 chars, different from the 32 digit seed) is consistent across out extension and the shell. Run a few updates on the doc in the extension, and the uuid remains unchanged. For basis, I used the seed from the mongo docs. The generated UUID matches the example through the updates.

Hope this helps!

[Danlock]

The fix has been merged. I’ve used it and nothing appears to be on fire yet.

One thing to keep in mind is that it updates a document by overwriting it, so you have to be careful not to to overwrite other changes.