Enhance the built-in memory connector to correctly support nested
queries for arrays in addition to objects.
E.g. if "friends" is an array of objects containing "name", then
{ where: { "friends.name": "Jane" } } should match records containing
a friend called "Jane".
When running the tests on Node v0.10, setup `global.Promise`
with Bluebird implementation. That way we don't have to run
this setup in the test suite of each kv connector.
Models attached to a KeyValue connector get the following *static*
methods:
Color.set(key, value);
Color.set(key, value, ttl);
Color.set(key, value, { ttl: ttl });
Color.get(key);
Color.expire(key, ttl);
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]