_objectifyId / ObjectID.isValid converts legit string IDs to Mongo ObjectId

[jscottsf]

Steps to reproduce

1. Assume a Mongo collection that has documents with _id fields of type string rather than ObjectId.
2. Now try to get() a document with a string _id that ObjectID.isValid considers to be a valid ObjectId. E.g. service.get('my-string-id'). The call fails to find the document since the string "my-string-id" is cast to an ObjectId.

Actual behavior

The get() call fails since _objectifyId blindly casts a passed _id. Since the documents are stored with string _id values, the call fails to find the documents.

Expected behavior

The decision to cast a string _id to ObjectId or leave it as string should be configurable in the service options. The service allows you to configure the name of the "id" field, but not whether it should be casted. Note that the field MUST be named "_id" for Mongo to consider it a primary key anyway.

In short, it's possible to have a field named "_id" and have it be of the type string. _objectifyId should not cast it if you want it to remain as string.

Note

From the MongoDB manual: The field name _id is reserved for use as a primary key; its value must be unique in the collection, is immutable, and may be of ANY TYPE other than an array.

[daffl]

If we don't convert to object ids then generated id's won't work anymore. What would probably work for you is to extend the adapter and override _objectifyId:

const { Service } = require('feathers-mongodb');

class MyService extends Service {
  _objectifyId(id) {
    return id;
  }
}

I'm not sure what else can/should be done to solve this.

[jscottsf]

Agreed. We have a mix of generated and application IDs. So doing both is necessary. Your suggestion was exactly how I solved it, tho wasn't sure if it would be a recommended practice to override the "private" member _objectifyId. Since you suggested this, works for me!