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();
})
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',
},
});
[back-port of #955]
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.
[back-port of #911]
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.
[back-port of #904]
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.
Add datasource and model setting `normalizeUndefinedInQuery`
to determine how it will handle undefined values. Options:
- nullify : converts undefined to null
- throw : throw an error on undefined value
- ignore : strip the key where undefined value is found
The default operation is to strip the key.
If the PK has a definition like
```
"mysql": {
"dataType": "CHAR",
"dataLength":36,
"nullable":"N"
}
```
dataLength is ignored when the PK is used as a foreignKey in other models
Adds support for the ability to query embedsMany models from the parent.
Fix a memory connector bug that could occur when having an "or" or "and"
clause combined with another property. In that case, the and would revert
true for 'Paul McCartney'
```
{name:'John Lennon',and: [{role:'lead'}, {vip:true}]}}
```
Return `info.count` to the callback to indicate whether the model
instance was deleted or not. When Model's `settings.strictDelete`
is true, return 404 error when the model instance was not found.
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.
Changes the after `save` callback in the memory connector to use the
`fromDb` method to deserialize the data passed back to upsert and
updateAttributes methods.
Sub models sometimes need to customize the properties from the base model.
This change allows each sub model has its own copy of the base property
definition to avoid potential conflicts across multiple sub models of the
same base.