Allow direct save of changes on embedded model to be persisted on
parent document.
Person.embedsOne(Address);
Person.findById(someId)
.then(function(p){
var address = p.addressItem();
address.street = 'new street'
// This will now persist changes on parent document
return address.save();
})
[forward-port of #949]
The setting controls the strict mode used for embedded property types,
for example the type of "address" property in this model definition:
modelBuilder.define('TestEmbedded', {
name: 'string',
address: {
street: 'string',
},
});
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
gunjpan
Amir Jafarian
Candy
Dimitris Halatsis
Alex Pitigoi
Sequoia McDowell
Miroslav Bajtoš
Simon Ho
Raymond Feng
Raymond Feng
Raymond Feng
Ryan Graham
bitmage
Horia Radu
Amir Jafarian
Jue Hou
Miroslav Bajtoš
Farid Nouri Neshat
Bert Casier