[2.0] Add createModelFromConfig and configureModel()

[bajtos]

Add new API allowing developers to split the model definition and
configuration into two steps:

1. Build models from JSON config, export them for re-use:

   var Customer = loopback.createModelFromConfig({
     name: 'Customer',
     base: 'User',
     properties: {
       address: 'string'
     }
   });

2. Attach existing models to a dataSource and a loopback app,
   modify certain model aspects like relations:

   loopback.configureModel(Customer, {
     dataSource: db,
     relations: { /* ... */ }
   });

Rework app.model to use loopback.configureModel under the hood.
Here is the new usage:

var Customer = require('./models').Customer;

app.model(Customer, {
  dataSource: 'db',
  relations: { /* ... */ }
});

In order to preserve backwards compatibility with loopback 1.x,
app.model(name, config) calls both createModelFromConfig
and configureModel.

See strongloop/loopback-example-offline-sync#13 for background of this change.

/to @ritch @raymondfeng please review

[ritch]

@example isn't supported by strong-docs.

[bajtos]

I thought I've seen a pull request adding that support recently. I checked strong-docs commits and could not find it anymore.

Never mind, I'll fix this and use **Example** instead of @example.

[ritch]

Nice to have:

Model.assertIsModel(Model)

[bajtos]

Ad Model.assertIsModel(Model) and DataSource.assertIsDataSource(dataSource) - perhaps we should get rid of it completely and use ModelCtor.prototype instanceof Model and dataSource instanceOf DataSource?

[ritch]

....sigh

We need to fix this. You shoulnd't need to use a unique name here.

[bajtos]

See @raymondfeng comment in the discussion in loopbackio/loopback-datasource-juggler#119:

The model names have to be unique

How else do you want to conform to this requirement in tests that are creating (defining) many new models?

[ritch]

I think its out of scope for this PR.

We should remove that requirement, that is my point.

[ritch]

Ad Model.assertIsModel(Model) and DataSource.assertIsDataSource(dataSource) - perhaps we should get rid of it completely and use ModelCtor.prototype instanceof Model and dataSource instanceOf DataSource?

This is a good idea.

[ritch]

Somehow the tests are failing...?

Otherwise this LGTM. Feel free to defer the minor changes to another PR.

[bajtos]

Somehow the tests are failing...?

There are two problems:

1. npm install fails with EPEERINVALID, because loopback-testing has a peer dependency on loopback and npm fetches a 1.x version instead of 2.0.0-betaX. Perhaps we should remove the peer dependency?
2. Two tests are failing on the server, even though they are passing locally. The errors don't provide enough information to track down the problem :( I'll try to investigate this in a different pull request.

[henrytseng]

Just joining this issue now. Looks like I'm late:

I like the models/lib, models/index.js idea but the loading order probably doesn't need to be dependent on order of require statements.

What do you think about building a priority system into models where each time a model extends another model priority++. To allow for tracking model loading order.

Not sure if you're allowing access to the inherited model's prototype but that would allow access to late binding model methods?

[bajtos]

What do you think about building a priority system into models where each time a model extends another model priority++. To allow for tracking model loading order.

@henrytseng It will not work. If you want to define a Car model extending a Vehicle model, the Vehicle must be already defined.

I agree the order of require statements in index.js is not the best way. Here is what you can do instead: in the file defining the subclass model, require the file defining the base model..

var loopback = require('loopback');

 // ensure the base class is defined
require('./vehicle');

var Car = module.exports = loobpack.createModel(require('./car.json'));

//etc.

Not sure if you're allowing access to the inherited model's prototype but that would allow access to late binding model methods?

The Car model in the example above has a copy of all Vehicle properties that were defined at the time when loopback.createModel was created. Car's prototype is inheriting from Vehicle's prototype, thus it inherits all prototype methods and the following statement is true: new Car() instanceof Vehicle.

Did I answer your question?

[bajtos]

See also #324.

[ritch]

I agree the order of require statements in index.js is not the best way. Here is what you can do instead: in the file defining the subclass model, require the file defining the base model..

Since this information (the ordering which models should be defined) is determinable, I think we should take that into account internally and require them in the correct order. The downside is that the algorithm to determine this priority isn't trivial.

[bajtos]

strongloop/loopback-boot#10 implemented a mechanism where the models are automatically required by the bootstrapper in correct order. See the pull request for more details.