105 lines
4.3 KiB
Markdown
105 lines
4.3 KiB
Markdown
# List of notable changes made between 2.x and 3.0
|
|
|
|
All breaking changes must be described here. When adding a new entry,
|
|
always describe the impact on users and instructions for upgrading
|
|
applications from 2.x to 3.0.
|
|
|
|
See also https://github.com/strongloop/loopback/blob/master/3.0-DEVELOPING.md
|
|
for more details.
|
|
|
|
## Always use bluebird as promise library
|
|
|
|
In version 3.0, we always use bluebird as our promise library
|
|
instead of `global.Promise`.
|
|
We consider Bluebird API a part of LoopBack API from now on,
|
|
you are welcome to use any Bluebird-specific methods in your applications.
|
|
|
|
If you are using LoopBack with a custom promise implementation provided
|
|
via `global.Promise`,
|
|
you will have to check all places where you are using non-standard promise API
|
|
and update them to use Bluebird API instead.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/790)
|
|
for more details.
|
|
|
|
## DAO.find provides ctx.data in "loaded" hook
|
|
|
|
When implementing "loaded" hook for `DAO.find` method, we have mistakenly
|
|
implemented a version that sets `ctx.instance` instead of `ctx.data`. This
|
|
defeats the purpose of the "loaded" hook, which is to allow hooks to modify
|
|
the raw data provided by the datasource before it's used to build a model
|
|
instance.
|
|
|
|
This has been fixed in 3.0 and the "loaded" hook now consistently provides
|
|
`ctx.data` for all operations. If you have a "loaded" hook handler that
|
|
checks `if (ctx.instance)` then you can remove this condition together with
|
|
the branch that follows.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/commit/30283291?w=1)
|
|
for more details.
|
|
|
|
## DAO.create no longer returns the instance(s) created
|
|
|
|
While implementing support for promises in `DAO.create`, we found that this
|
|
method returns the instance object synchronously. This is inconsistent with
|
|
the usual convention of accessing the result via callback/promise and it may
|
|
not work correctly in cases where some fields like the `id` property are
|
|
generated by the database.
|
|
|
|
We have changed the API to be consistent with other DAO methods: when invoked
|
|
with a callback argument, the method does not return anything. When invoked
|
|
without any callback, a promise is returned.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/918)
|
|
for more details.
|
|
|
|
## Applying an undefined mixin to a LoopBack model throws an error
|
|
|
|
When applying an undefined mixin to a LoopBack model, a warning message was
|
|
logged regarding the invalid mixin, which needs to be addressed rather than
|
|
silently ignored. This has been fixed in 3.0, therefore an undefined mixin
|
|
applied to a LoopBack model will throw an error that needs to be handled.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/944)
|
|
for more details.
|
|
|
|
## Remove deprecated model hooks and model events
|
|
|
|
The following deprecated model events are now removed. Please upgrade your code by using
|
|
operation hooks in its place.
|
|
|
|
Model events
|
|
* changed
|
|
* deletedAll
|
|
* deleted
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/965)
|
|
for more details.
|
|
|
|
## Model property names with dot(s) generates an error
|
|
|
|
Instead of showing a deprecation warning for model property names with dots,
|
|
for example, `customer.name: 'string'`, an error is thrown in 3.0 for
|
|
enforcing use of valid model property names.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/947) for more details.
|
|
|
|
## Remove wrapper `DataSource.registerType()`
|
|
|
|
`DataSource.registerType() method is removed as it was a wrapper for
|
|
`ModelBuilder.registerType()` and was deprecated.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/976)
|
|
for more details.
|
|
|
|
## Disallow array input for updateOrCreate function
|
|
|
|
Allowing updateOrCreate to accept an array as input would only work when
|
|
creating new model instances (not updating them), so this support has been
|
|
removed. Please use `create` function instead (array inputs only worked to
|
|
create new instances with this method before). If you would like to perform a
|
|
bulk `updateOrCreate`, you could use `async.each` or `Promise.all` to
|
|
repeatedly call `updateOfCreate` for each instance.
|
|
|
|
See [related code change](https://github.com/strongloop/loopback-datasource-juggler/pull/889) here.
|