2.8 KiB
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 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 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 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 for more details.