URGENT 5.2.0: _Cannot specify a custom index on _id, MongoDB does not allow overwriting the default _id index_ is not correctly implemented

[jlchereau]

5.2.0 took a too restrictive measure to fix #6605:

• it makes sense not to create a duplicate index on _id
• it does not make sense to prevent any index designating _id as part of a list of indexed fields, e.g.:
  • { _categoryId: 1, _id: 1}
  • { _userId: 1, _id: 1 }

With 5.2.0, any index containing _id: 1 raises an error because of https://github.com/Automattic/mongoose/blob/master/lib/model.js#L1208

if (index[0]._id != null) {

should be replaced with something like

if (Object.keys(index[0]).length === 1 && index[0]._id != null) {

[bruun]

I agree this should not raise an error, at least not in a minor release. Perhaps emitting an error would be more suitable?

However: Does compound indexes with _id even make sense at all, since it is unique?

[jlchereau]

{ _id: 1, _categoryId: 1 } does not make sense but { _categoryId: 1, _id: -1 } makes perfect sense when sorting by category then by creation date.

[vkarpov15]

@jlchereau thanks for the clarification and sorry about the trouble. We'll convert this to printing a warning if an index only has _id and no other fields.

[jlchereau]

In my opinion, you can keep throwing an error, but only when:

1. the index is a single-field index designating _id, because it is then a duplicate;
2. the index is a multi-field (compound) index and _id is not the last field (since _id ensures uniqueness it has to be the last field of the compound index).

[vkarpov15]

I think that's the case as well, but I'm going to err on the side of caution. When you make a mistake, there's very rarely just one mistake, so for now we'll keep it as a warning and consider adding the error back later if there aren't any issues with the warning.