JSON parser does not cast _id property to ObjectID

[axelpale]

JSON parse is a nice thing to have for development as the backup is human readable. However, I find it hard to use, because _id properties read from JSON are casted to strings instead of ObjectIDs. They must be casted to ObjectID, see e.g. this StackOverflow entry.

The insertion of a string-typed _id does not cause error by itself, but leads to inconsistent _ids. For example, documents { _id: "57e5714f6c34f946dd337fe3" } and { _id: ObjectId("57e5714f6c34f946dd337fe3") } do not violate _id uniqueness and both can exist in a collection at the same time. This obviously is not desired behavior.

After index.js line 186, one should:

doc._id = new ObjectId(doc._id);

where

var ObjectID = require('mongodb').ObjectID;

I guess one must use the default bson parser until this issue is fixed.

[hex7c0]

BSON is default parser
I know that JSON is error-prone with certain types (ObjectID, Date), but I I would not like to cast type on parsing

[axelpale]

Thanks for the reply! Oh, I see. MongoDB allows _id field to have any type although ObjectID is the default. With the typecasting I suggested, those _id fields that are alternatively typed by purpose would break. What a naive suggestion, my bad.

However, the problem still remains. I wonder how the official mongodump solves the issue... Well, it completely avoids it by allowing only BSON.

I think this issue puts the whole feature of backupping and restoring JSON into question. The human readability is damn convenient but I guess that everybody agrees that if we backup a database into JSON, then restoring it must yield exactly same content. I strongly believe that users strongly expect such a requirement. With JSON, the requirement is not fulfilled even with a trivial database. So, what should we do?

What do you think about the following alternative paths to close the issue:

1. deprecate JSON and custom parser support in the next major version
2. document JSON feature so that a user clearly understands the casting issues.
3. store type information into a file during JSON backup and use that info in restoration.

[hex7c0]

I prefer the document (2) choice

because BSON is default parser, and store type information is too dangerous