Fix the problem where `registry.defaultDataSources` has two instances:
- `require('loopback').defaultDataSources` used by
`loopback.autoAttach()`
- `require('./registry').defaultDataSources` used by
`app.dataSource`.
I am intentionally leaving out unit-tests as the whole `autoAttach`
feature is going to be deleted before 2.0 is released.
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`.
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.
Expose the juggler's DataSource constructor as `loopback.DataSource`.
The DataSource constructor is most useful to check
for `instanceof DataSource`, but it also makes the loopback API more
consistent, since the API is already exposing all pre-built Models.
Fix the problem where `registry.defaultDataSources` has two instances:
- `require('loopback').defaultDataSources` used by
`loopback.autoAttach()`
- `require('./registry').defaultDataSources` used by
`app.dataSource`.
I am intentionally leaving out unit-tests as the whole `autoAttach`
feature is going to be deleted before 2.0 is released.
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.
Use
@property {Object} [properties]
instead of
@property {Object=} properties
for optional properties.
Use `**example**` instead of `@example`, since strong-docs don't support
the latter.
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`.
Miroslav Bajtoš
Miroslav Bajtoš
crandmck
Raymond Feng
Raymond Feng