It was previously completely undocumented. There are additional methods that add promises but I figure accurately documenting some is better than none. :)
Simplify DataAccessObject.create() and stop returning the
instance/array of instances. Users should always use callback (or
returned promise) to get the instance(s) created.
create() triggers
- before save
- after save
updateById() triggers
- before save
- after save
destroy() triggers
- before delete
- after delete
The implementation here is intentionally left with less features
than the regular DAO methods provide, the goal is to get a partial
(but still useful!) version released soon.
Limitations:
- `before save` & `after save` hooks don't provide `ctx.isNewInstance`
- async validations are not supported yet
- `persist` and `loaded` hooks are not triggered at all
- `before delete` hook does not provide `ctx.where` property and
it's not possible to change the outcome of `destroy()` using this
hook. Note that regular DAO does support this.
- updating embedded instances triggers update of the parent (owning)
model, which is correct and expected. However, the context provided
by `before save` and `after save` hooks on the parent model is sort of
arbitrary and may include wrong/extra data. The same probably applies
to the scenario when deleting embedded instances triggers update of
the parent model.
create() triggers
- before save
- after save
udpate() triggers
- before save
- after save
destroy() triggers
- before delete
- after delete
The implementation here is intentionally left with less features
than the regular DAO methods provide, the goal is to get a partial
(but still useful!) version released soon.
Make automatic validation optional on all CRUD methods in a loopback
model. This can be done in 2 ways
- set `automaticValidation` in the model settings
- set `validate` on the options passed when calling the crud methods
The options take precedence on the model setting.
By default the automatic validation remains true to be backwards
compatible
To replace incorrect location of capturing this condition in find() in
loopback-connector/lib/sql.js proposed earlier in
https://github.com/strongloop/loopback-connector/pull/34.
Being set to 'includeHasMany', findCaller option triggers injection of
PARTITION BY clause in buildColumnNames() in
loopback-connector-mssql/lib/mssql.js only when find() function is
called to process include filter with 'has many' relation.