loopback-datasource-juggler 3.0.0

3.0.0 Release Candidate

on Node.js NPM

This is the first Release Candidate release of the upcoming major version 3.0.

List of notable changes made between 2.x and 3.0:

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.

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
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 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
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 here.

Removing strict: validate and strict: throw

Given a user model definition as follow:

ds.define('User', {
  name: String, required: false,
  age: Number, required: false
})

var johndoe = new User({ name: 'John doe', age: 15, gender: 'm'});

• strict: false

  behavior will remain the same and unknown properties will be saved along with other properties

  //johndoe would be created as
  {
    id: 1,
    name: 'John doe',
    age: 15,
    geneder: 'm'
  }

• strict: 'validate' and strict: 'throw'

  are removed in favor of strict: true, and because non-empty string
  resolves as true, they will share the same behavior as strict: true

• strict: true's behavior change:

  Previously: (2.x)

  strict:true would silently removing unknown properties, and User instance will be created with unknown properties discarded

  johndoe.isValid(); //true
  //johndoe would be created as
  {
    id: 1,
    name: 'John doe',
    age: 15
  }

  New Behavior: (3.x)

  johndoe.isValid(); //false
  //johndoe would NOT be created and will result in the following error
  //ValidationError: The User instance is not valid. Details: gender is not defined in the model (value: 'm').

See related code change here.

Users cannot provide a custom id value when id is auto-generated

For security reason, the default value of config variable forceId is set to
true if a model uses auto-generated id. It means creating/updating instance
with a given id will return an error message like:

Unhandled rejection ValidationError: The `MyModel` instance is not valid.
Details: `id` can't be set (value: 1).

You can change forceId: false in model.json file to disable the check, eg:

Change config in common/models/MyModel.json:

{
  "name": "Product",
  "forceId": false
}

Then create a new instance with given id:

MyModel.create({
  id: 1,
  name: 'test',
}).then(function(modelInstance) {
  // Get the modelInstance with id = 1.
});