-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: 1.0.2
-
Component/s: None
-
None
The C driver currently considers DBRef objects invalid due to $-prefixing of their $ref, $id, and optional $db field names. All of the following embedded document values should past validation:
{ "$ref": <string>, "$id": <anything> } { "$ref": <string>, "$id": <anything>, "$db": <string> } { "$ref": <string>, "$id": <anything>, "foo": <anything> } { "$ref": <string>, "$id": <anything>, "$db": <string>, "foo": <anything> }
The last two examples may appear strange, but because DBRefs are simply embedded documents, they are permitted to contain additional fields (without $ prefixes, of course). Various ODMs take advantage of this to store additional metadata about references, such as the referenced document's class name.
So, the general rule about DBRefs is:
- They're embedded objects. A top-level document cannot be a DBRef, even if _id was to appear after $ref and $id in the BSON document field sequence.
- They require $ref and $id as the first and second fields, respectively.
- An optional $db field is permitted only as the third field.
- Additional fields may appear in after $id (if there is no $db) or $db, but they cannot have $ prefixes.
As a result of DBRef object notation not being valid (due to $ prefixes on its field names), users may be wrongfully encouraged to create DBPointer BSON types, which have been deprecated for many years.
- related to
-
SERVER-10777 Allow JSON Parser to support additional fields when parsing DBRefs
- Closed
-
SERVER-612 Allow Arbitrary Properties on DBRefs
- Closed
-
SERVER-9790 DBRef string representation should include $db
- Closed