Creates a new applyDefaultValues option on the Model constructor
defaulting to true, the current behaviour.
Updates the dao module to pass `{ applyDefaultValues: false }` to the
Model constructor during the updateOrCreate method when we assume an
update is happening.
- validateUpsert:true reports validation errors back to the callback
- validateUpsert:false does not call `isValid()` at all
- any other value report validation errors via `console.warn`
Fix the implementation of updateOrCreate (a.k.a. upsert) to validate
the model before calling the connector.
In order to preserve backwards compatibility, validation errors are
only logged via console.warn by default.
The correct behaviour, where validation errors fail the updateOrCreate
operation, can be enabled via new model setting "validateUpsert".
When the setting "persistUndefinedAsNull" is true,
the model will use `null` instead of `undefined` in
all property values.
- Known optional model properties are set to `null` when no value
was provided.
- When setting model properties, `undefined` is always converted
to `null`. This applies to both known (model-defined) properties
and additional (custom, dynamic) properties.
- The instance method `toObject()` converts `undefined` to `null` too.
Because `toJSON()` calls `toObject()` under the hood, the change
applies to `toJSON()` too.
Rename the second callback argument to `info` to make its purpose more
clear. Fix jsdoc comments, note that these comments are NOT shown
on http://apidocs.strongloop.com/.
ffcaa4e7 added a "data" argument to the callback function, which
shadowed the original data with the data returned by a connector.
Not all connectors are returning a data object though, in which case
the model instance ("this" object) is updated with wrong values.
This commit fixes the problem by renaming the second callback argument
to "unusedData".
"before save" hooks provide "ctx.isNewInstance" whenever "ctx.instance"
is set. Possible values:
- true for all CREATE operations
- false for all UPDATE operations
- undefined for "prototype.save"
"after save" hooks provide "ctx.isNewInstance" whenever "ctx.instance"
is set. Possible values:
- true after all CREATE operations
- false after all UPDATE operations
- undefined after "updateOrCreate" and "save"
Note: both "updateOrCreate" and "prototype.updateAttributes"
don't provide `ctx.instance` to "before save" hooks, therefore
`ctx.isNewInstance` it not provided either.
Before this commit, the following code would not work:
Change.updateOrCreate({...}, function(err, ch) {
// somewhere later, modify "ch" and save the changes
ch.save(cb);
});
"before delete" and "after delete" hooks receive `ctx.instance`
when a single model is being deleted.
"before save" hook receives `ctx.currentInstance` when triggered
by `prototype.updateAttributes()`.
Note that "after save" hook triggered by `prototype.updateAttributes()`
already provides `ctx.instance`.
When a callback is omitted from a DAO method, return a Promise that
resolves to the value normally passed to the callback of that method.
If a callback is provided, behave normally.
This API will use native ES6 promises if available. If not available,
or to force the use of another Promise library, you must assign the
global.Promise object.
e.g.:
global.Promise = require('bluebird')
Class methods affected:
- create
- updateOrCreate / upsert
- findOrCreate
- exists
- find
- findOne
- findById
- findByIds
- remove / deleteAll / destroyAll
- removeById / deleteById / destroyById
- count
- update / updateAll
Prototype methods affected:
- save
- delete / remove / destroy
- updateAttribute
- updateAttributes
- reload
Exceptions / edge cases:
- create() used to return the data object that was passed in, even if
no callback was provided. Now, if a callback is provided, it will
return the data object, otherwise it will return a Promise.
- If create() is provided an array of data objects for creation, it
will continue to always return the array. This batch creation mode
does not support promises.
- findOrCreate() has a callback of the form: cb(err, instance, created),
with the extra parameter indicating whether the instance was created
or not. When called with its promise variant, the resolver will
receive a single array parameter: [instance, created]
Signed-off-by: Clark Wang <clark.wangs@gmail.com>
remove undefined for creating data in findOrCreate
Signed-off-by: Clark Wang <clark.wangs@gmail.com>
getLastGeneratedUid instead of force an id
Signed-off-by: Clark Wang <clark.wangs@gmail.com>
The name "query" creates incorrect assumption that hook handlers
may return the result of a query to bypass database access.
That is far from true, since this hook is called also by methods
like `deleteAll` or `updateAll` that don't perform any SELECT query.
The commit 1fd6eff1 (intent-based hooks) introduced a subtle regression
in `.save()` method where dynamic property setters were invoked twice.
This commit fixes the problem by moving pre-save data normalization
into `before save` callback.
This patch introduces a new API for "intent-based" hooks. These hooks
are not tied to a particular method (e.g. "find" or "update"). Instead,
they are triggered from all methods that execute a particular "intent".
The consumer API is very simple, there is a new method
Model.observe(name, observer), where the observer is function
observer(context, callback).
Observers are inherited by child models and it is possible to register
multiple observers for the same hook.
List of hooks:
- query
- before save
- after save
- after delete
For queries, this is undesirable. It also affects
loopback-connector-mongodb's ability to perform nested queries (it
expects plain objects to work correctly, and to allow $elemMatch for
example).
Previously validations were appended to an array when configured. The
format was cumbersome, and led to issues. This refactors the
configuration into an object, as a property of the Model.
Note that if no validations have been configured, this property is
currently `undefined`.
Since one can call updateAttributes with any kind of properties (as
opposed to save, which uses toObject internally), any objects that
correspond to toObject should be handled as such. This is particularly
the case with List objects, as used by embedsMany.
Bryan Clark
Raymond Feng
Raymond Feng
Miroslav Bajtoš
Rus1
Pradnya Baviskar
Fabien Franzen
Miroslav Bajtoš
Pulkit Singhal
Partap Davis
rudzon
Clark Wang
Samuel Reed