|
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.
|