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:
```js
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:
```js
loopback.configureModel(Customer, {
dataSource: db,
relations: { /* ... */ }
});
```
Rework `app.model` to use `loopback.configureModel` under the hood.
Here is the new usage:
```js
var Customer = require('./models').Customer;
app.model(Customer, {
dataSource: 'db',
relations: { /* ... */ }
});
```
In order to preserve backwards compatibility,
`app.model(name, config)` calls both `createModelFromConfig`
and `configureModel`.
Change the tests creating new users so that they send valid user data,
in order to prevent 422 "validation failed" responses.
Upgrade loopback-testing to 0.2.0.
Allow browserified applications to explicitly register connectors
to use in data-sources via `app.connector(name, exportsFromRequire)`.
Include built-in connectors like `Memory` and `Remote` in the registry.
Modify `dataSourcesFromConfig()` to resolve the connector via
`app.connectors` first and only then fall back to auto-require
the connector module.
Support flat structure of model config objects, where model options
are set as top-level properties.
Before:
Customer: {
dataSource: 'db',
options: {
base: 'User'
}
}
Now:
Customer: {
dataSource: 'db',
base: 'User'
}
Make `loopback.rest` self-contained, so that authentication works
out of the box.
var app = loopback();
app.enableAuth();
app.use(loopback.rest());
Note that cookie parsing middleware is not added, users have to
explicitly configure that if they want to store access tokens
in cookies.
Modify `loopback.token` to skip token lookup when the request already
contains `accessToken` property. This is in line with other
connect-based middleware like `cookieParser` or `json`.
Relax the assertions to verify only the integer part of the distances.
The decimal part is subject to small variances depending on the exact
implementation of floating-point arithmetic.
For example, the distance calculated on Node v0.11.13 is different
than the distance calculated on Node v0.10.x.
* it allows to find related object via URL scope
GET /api/categories/{cat-id}/products
* it allows to find related objects via where filter
GET /api/products?filter[where][categoryId]={cat-id}
(skipped for now)
* it includes requested related models in `find`
GET /api/categories/findOne
?filter[where][id]=CAT-ID&filter[include]=products
* it includes requested related models in `findById`
GET /api/categories/{cat-id}?include=products
(skipped for now)