RoleMapping.findOrCreate always create new mapping in lp 3.x

[alemhnan]

I am migrating from LoopBack 2 to 3.x. I have this piece of code in a boot script:

const rm = { 
  principalType: RM.USER, 
  principalId: userId.toString(),
  roleId: roleId.toString(),
};
return RoleMapping.findOrCreate({ where: rm }, rm);

In Loopback 2.x it was behaving as expected, in 3.0 the findOrCreate always create a new instance.

I tried to update also just the loopback-datasource-juggler using version 2 but the problem apparently is in loopback 3.0 and not the juggler.

Additional information

darwin x64 6.10.0
Node v6.10.0
├── loopback@3.4.0
├── loopback-boot@2.23.0
├── loopback-component-explorer@4.1.1
├── loopback-component-model-diagram@0.3.0
├── loopback-component-storage@3.1.0
├── loopback-connector-mongodb@3.0.1

[alemhnan]

Upon further inspection I discovered that the problem is with the property principalId.

I cannot query by principalId and get a result using .findOne. I am using mongodb. I suspect that since the property is stored as String type there might be some confusion in the query.

I tried anyway converting in string using .toString, manually quoting and even hard coding an object id with no success.

[bajtos]

Hi @alemhnan, thank you for reporting the issue and providing detailed information.

I believe this is a duplicate of #3121 (see also rejected #3198).

The solution is to enable strictObjectIDCoercion in RoleMapping settings by updating your application's server/model-config.json - see strongloop/loopback-workspace#437

    {
       name: 'RoleMapping',
       dataSource: 'db',
+      options: {
+        strictObjectIDCoercion: true,
+      },
       public: false,
     },

I think we should capture this information in LoopBack 3.0 release notes and the migration guide.

@alemhnan would you mind contributing this doc improvement yourself? See http://loopback.io/doc/en/contrib/doc-contrib.html to get started.

cc @crandmck

[alemhnan]

Thanks a lot for the fast reply and for pointing out the solution.
I tried it, and it's indeed working.

I am going to contribute to the docs as well. I will try to submit a PR early next week.

[bajtos]

Thanks a lot for the fast reply and for pointing out the solution.
I tried it, and it's indeed working.

That's great to hear!

I am going to contribute to the docs as well. I will try to submit a PR early next week.

Awesome ❤️

I am going to reopen this issue and keep it open as a reminder for us (and anybody else in the community) that the docs are not updated yet.

[ebarault]

i missed the fix mentioned [here] 👍 (#3121 (comment)) @bajtos
as of now i was using the js bootscript approach consisting of

var ObjectID = RoleMapping.getDataSource().connector.getDefaultIdType();

// Because of this: https://github.com/strongloop/loopback-connector-mongodb/issues/1441
RoleMapping.defineProperty('principalId', {
  type: ObjectID,
});

shouldn't the new projects templates be updated as well as long as you did for projects generated with the slc cli?

further on: shouldn't it be made a feature flag so this can be activated out of box in next major release ?

[bajtos]

Thank you @ebarault for chiming in.

shouldn't the new projects templates be updated as well as long as you did for projects generated with the slc cli?

I am afraid I don't understand. What do you mean by "new projects templates"? AFAIK, we have only one set of templates, and that's the set used by our CLI tooling (slc, lb, apic) - see strongloop/loopback-workspace#437

further on: shouldn't it be made a feature flag so this can be activated out of box in next major release ?

IMO, this is already a feature flag. I guess what we need is a list of feature flags to toggle in the next major version. This issue query may be a good start.

[ebarault]

project template

my bad, i was imprecise: i meant sample project starters: baremetal project skeletons to be used to bootstrap a new project without the cli. But maybe i got confused in thinking there are such starters?

feature flag

arff yes, you're right in a sense. What I meant is a global activation of this feature for any model using some setting in config.json so people don't need to get concerned about such internal machinery (further on, the name itself is quite unrelated with the given issue)

[bajtos]

i meant sample project starters: baremetal project skeletons to be used to bootstrap a new project without the cli.

Makes sense. I think the most important one to update is https://github.com/strongloop/loopback-sandbox, which we use for reproducing bugs.

Then we have a bunch of example repositories. @superkhau what's the process to update our example repos to the latest project layout?

[bajtos]

What I meant is a global activation of this feature for any model using some setting in config.json so people don't need to get concerned about such internal machinery (further on, the name itself is quite unrelated with the given issue)

Makes sense. OTOH, I am personally not familiar enough with the side effects of this setting to be able to tell whether it's a good or a bad idea to enable it app-wide.

I think the existing flag is just a workaround for the fact that LoopBack does not handle the type of foreign keys correctly, especially the ObjectID type. @superkhau and @raymondfeng were looking into ways how to fix that root cause, but there was no actionable outcome identified IIRC. It's a tricky problem.