When a public model is added to an application and the model has change
tracking enabled, its Change model is added to the public models.
Before this change, conflict resolution in the browser was not working,
because it was not possible to fetch the remote change.
Most applications report the URL when started (at least the apps we
are scaffolding using loopback-workspace). Constructing the URL in the
loopback core allows us to simplify the templates and reduce the amount
of repeated code.
Move isBrowser and isServer from lib/loopback to a new file lib/runtime.
Move all Model and DataSource related methods like `createModel` and
`createDataSource` to lib/registry.
Remove the circular dependency between lib/application and lib/loopback,
by loading lib/registry and/or lib/runtime instead of lib/loopback
where appropriate
This commit is only moving the code around, the functionality should
not be changed at all.
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`.
Move isBrowser and isServer from lib/loopback to a new file lib/runtime.
Move all Model and DataSource related methods like `createModel` and
`createDataSource` to lib/registry.
Remove the circular dependency between lib/application and lib/loopback,
by loading lib/registry and/or lib/runtime instead of lib/loopback
where appropriate
This commit is only moving the code around, the functionality should
not be changed at all.
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 with loopback 1.x,
`app.model(name, config)` calls both `createModelFromConfig`
and `configureModel`.
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'
}
creating a cache
- Use the SharedClass class to build the remote connector
- Change default base model from Model to DataModel
- Fix DataModel errors not logging correct method names
- Use the strong-remoting 1.4 resolver API to resolve dynamic remote
methods (relation api)
- Remove use of fn object for storing remoting meta data
Add a compatibility layer that allows applications based on LB pre-v1.6
to work with 1.6 versions with a minimum amount of changes required.
New flag(s):
compat.usePluralNamesForRemoting
Remove the inconsistency between model names used by LoopBack app and
datasource-juggler (modelName, e.g. User) and the name used by
strong-remoting (pluralModelName, e.g. Users).
This way the class name in the strong-remoting metadata can be used
by client-code generators. Before this change, the generators would
produce method names like `Users.login`.
Remove docs/api-app.md and docs/api.md, as they are no longer referenced
from docs.json.
Add few missing bits from docs/api-app.md to lib/application.js
comments.
Fix the jsdox for `app.installMiddleware` to use `app.once` for
listening on 'middleware:*' events.
The previous doc version using `on` was a sort of preliminary
pessimisation, becase the event handlers would stay in the heap
for the whole life-time of the app, even though they won't be called
more than once.
Allow loopback users to configure API root via config file, instead of
editing app.js generated by loopback-workspace.
Allow loopback plugins to discover the path where the REST adapter is
mounted.
Raymond Feng
Fabien Franzen
Raymond Feng
Miroslav Bajtoš
Miroslav Bajtoš
Karl Mikkelsen
Ritchie Martori
Samuel Reed
crandmck
Guilherme Cirne
Aurelien Chivot