LoopBack models should inherit config.options from the parent

[bajtos]

When LB developer wants to access built-in LB models via app.models, he has to define subclasses in models.json. The current implementation requires that a lot of config options of the base model must be repeated in the subclass definition.

This has several disadvantages:

1. It's difficult to add a built-in model to your app, especially if you are new to loopback.
2. If we modify the built-in model (e.g. by adding another relation), existing application will break after upgrade.

Below are the use cases I discovered while writing E2E tests for loopback-angular.

datasource

app.model('MyUser', {
  options: { base: 'User' },
  dataSource: 'db'
});

Result:

assert.js:92
  throw new assert.AssertionError({
        ^
AssertionError: MyUser is referencing a dataSource that does not exist: "undefined"
    at modelFromConfig (/Users/bajtos/src/loopback/loopback/node_modules/loopback/lib/application.js:545:3)
    at Function.app.model (/Users/bajtos/src/loopback/loopback/node_modules/loopback/lib/application.js:115:38)
    [etc.]

Since the new model is a subclass of a built-in model, it should use the same datasource that was configured for the User model.

If the datasource of the base class was not resolved yet, but it has autoAttach property, then the process of attaching the subclass to a datasource should be deferred to loopback.autoAttach.

relations

var user = app.model('user', {
  options: {
    base: 'User',
  },
  dataSource: 'db'
});

app.enableAuth();

var credentials = { email: 'foo@foo.com', password: 'password'};
user.create(credentials, function(err) {
  if (err) throw err;
  user.login(credentials, function(err) {
    if (err) throw err;
    console.log('login passed');
  });
});

Result:

/Users/bajtos/src/loopback/loopback/lib/models/user.js:152
          user.accessTokens.create({
                            ^
TypeError: Cannot call method 'create' of undefined
    at /Users/bajtos/src/loopback/loopback/lib/models/user.js:152:29
    at /Users/bajtos/src/loopback/loopback/lib/models/user.js:202:7
    at /Users/bajtos/src/loopback/loopback/node_modules/bcryptjs/bcrypt.min.js:40:101
    [etc]

To fix this problem, one has to re-define User relations:

var user = app.model('user', {
  options: {
    base: 'User',
    relations: {
      accessTokens: {
        model: 'AccessToken',
        type: 'hasMany',
        foreignKey: 'userId'
      }
    }
  },
  dataSource: 'db'
});

[raymondfeng]

The requirement seems to boil down to dependencies between models and have a systematic way to resolve/inject the dependencies.

[glesage]

Any updates on this? Is the manual way still the best way?

[bajtos]

@glesage No updates so far.

[bajtos]

Since the new model is a subclass of a built-in model, it should use the same datasource that was configured for the User model.

This is no longer relevant, LoopBack 2.0 decoupled datasources config from model definition.

The current implementation requires that a lot of config options of the base model must be repeated in the subclass definition.

This is still relevant. The implementation would most likely break backwards compatibility.

Related issue: #397 A better way for customizing built-in models and models from components

[bajtos]

Let's bring this issue back to life. For the upcoming 3.0 release, I am proposing to modify juggler's model builder to inherit model settings when subclassing a new model.

app.model('MyUser', {
  options: { base: 'User' },
  dataSource: 'db'
});
// expected outcome:
assert(MyUser.settings.__proto__ === User.settings);

[shyd0w]

I think that would be great! Options is the inheritance of the setting?

[bajtos]

/cc @davidcheung

[davidcheung]

Loosely related #1485

[bajtos]

ACLs are not inherited either, see #2270.

As for inheriting relations, pure prototypal inheritance may not be enough. Consider this scenario:

We have a parent model User which has a relation

accessTokens: {
  model: 'AccessToken',
  type: 'hasMany',
  // this is omitted: foreignKey: 'userId'
}

When attached to a datasource, foreignKey property is automatically inferred and AccessToken.userId property is defined by juggler.

Now when we create Customer extending User, the foreign key for relation accessTokens will be generated as AccessToken.customerId, which may break code relying on userId property name.

A possible solution is to always fill in foreignKey before inheriting model settings.

[bajtos]

We agreed this required a bit of research to find out what and how should be inherited when subclassing a model. We don't have bandwidth to address it in 3.0 time.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.