Mongo Object Ids get converted to Strings

[arlaneenalra]

I ran across this issue when dealing with related documents with a Mongo DB backend. I have a models.json file that looks contains something similar to:

{
  "service": {
    "properties": {
      "slug": {
        "type": "String"
      },
      "title": {
        "type": "String"
      },
      "link": {
        "type": "String"
      },
      "subtitle": {
        "type": "String"
      },
      "intro": {
        "type": "String"
      },
      "content": {
        "type": "String"
      },
      "icon": {
        "type": "Object"
      },
      "image": {
        "type": "Object"
      }
    },
    "public": true,
    "dataSource": "db"
  },
  "serviceCategory": {
    "options": {
      "relations":{
        "services": {
          "model": "service",
          "type": "hasMany"
        }
      }
    },
    "properties": {
      "title": {
        "type": "String"
      },
      "tagline": {
        "type": "String"
      },
      "subtitle": {
        "type": "String"
      },
      "intro": {
        "type": "String"
      },
      "content": {
        "type": "String"
      },
      "image": {
        "type": "object"
      }
    },
    "public": true,
    "dataSource": "db",
    "plural": "serviceCategories"
  }
}

When retrieving services with a request similar to /api/serviceCategories/<id>/services I get back objects that have a serviceCategoryId field with the string equivalent of a Mongo ID. If a change is made to one of those retrieved documents and it is updated via a PUT request, what was an ObjectId is replaced with a string and Mongo loses the relationship. (i.e. the document is no longer retrievable via the original request.)

In a conversation over IRC rfeng suggested that creating a custom ObjectId type for Mongo might be a solution to this issue and that I should file a bug here for direction on how to go about that. Thinking about the issue, I'm wondering if this should be handled when the initial relationship is defined, that appears to be where the foreign key field is implicitly created. In either event, an ObjectId type is likely a requirement.

[arlaneenalra]

I've done a little more digging on this. It appears that the loopback-connector-mongo has a defineForeignKey method that sets the type for foreign key fields to an closure that creates ObjectIds. Unfortunately, it looks like this is not getting called in all cases and that the ObjectId closure itself is not getting called in all cases either. I'm not sure why this is or the best way to solve it but this is very problematic issue.

[ritch]

A runnable example / test that reproduces this issue would be helpful. I agree that it is a big issue.

/cc @raymondfeng

[arlaneenalra]

Try this out:

https://github.com/arlaneenalra/strongloop-id-issue

I used slc to create a new project, setup two models in models.json (objA and objB) and setup a chain or http requests that demonstrate one case of this issue in test.js. Just check it out, run npm install, npm start, and npm test in another window.

The final console.log should show the created objB after the update, instead, it shows an empty list. Let me know if that helps ....

Note: This is a Mongo specific issue and does not appear to impact the default memory store.

[raymondfeng]

Thanks for the test case. I was able to reproduce the problem. I did a quick test to the mongodb connector so that defineForeignKey returns String instead of ObjectID and the test passes.

I guess there are a couple things involved:

1. LoopBack should be able to derive the foreign key type from the primary key property type.
2. LoopBack connectors should be able to nominate the id types and convert id values back and forth. For example, MongoDB supports String, Number, ObjectID while MySQL supports String and Number.

[arlaneenalra]

That sums up the issue pretty well. ObjectID would work fine if they were being consistently applied. The key is consistently using the same type all the time.

[arlaneenalra]

Any update on this? Is there something that needs to be revisited in the pull request?

[raymondfeng]

loopbackio/loopback-connector-mongodb#13

[raymondfeng]

We have a few PRs under review, they should fix the issue once they are merged.

[raymondfeng]

#70 is merged and released under 1.3.2. It should fix the problem.

[codejie]

please check Role-Mapping model, I can not insert the principalId with ObjectId. And if it was not ObjectId, ACLs will not find this mapping between user and role.

{
"_id" : ObjectId("58c2185a6024ee2f1705d1ec"),
"principalType" : "USER",
"principalId" : "58c1380699220526baa9477b",
"roleId" : ObjectId("58c21117df1db02b1425882c")
}