updateAttributes operational hooks: use instance, not where

[fabien]

Because it operates on an instance, you know ...

[raymondfeng]

I ran into the same confusion too. updateAttributes is an instance method, the ctx.instance should be set. We should also keep ctx.data to the data argument which contains the name/value pairs to be changed.

[fabien]

Sounds great @raymondfeng - it's a blocking issue for me at the moment. Any chance of pushing this soon?

[raymondfeng]

@fabien Do you have time to submit a patch?

[fabien]

Hmm, I'll try tonight - but I'm guessing @bajtos is more familiar with the ins-and-outs.

[fabien]

@raymondfeng working on it - #474 as well

[fabien]

@raymondfeng this is a first stab at it - I'll try to tackle #474 later tonight - please review

[fabien]

@raymondfeng I'm thinking it makes sense to propagate an operation object as part of the context as a generic 'stash' for keeping state between before and after:

Model.observe('before delete', function(ctx, next) {
  if (ctx.instance) {
    ctx.operation.instances = [ctx.instance];
  } else {
    Model.find({ where: ctx.where }, function(err, instances) {
      ctx.operation.instances = instances;
      next();
    });
  } else {
    next();
  }
});

Model.observe('after delete', function(ctx, next) {
  if (ctx.operation.instances) {
    async.forEach(ctx.operation.instances, removeFromDisk);
  } else {
    next();
  }
});

[bajtos]

Let me explain the reasons behind the current decision and why I think we should take a different approach.

1. The old hooks provided both the instance via "this" and data via function arg. It caused confusion as sometimes the correct approach was to change the properties via "this" and sometimes via "data" and it was not clear when to use which.
2. While updateAttributes operates on an instance, it performs a partial update. Originally I used ctx.instance in the "before save" hook, but that make it difficult to find out what modifications the user made, how to map the instance properties into the partial data to update. Especially in such way that when the user does not make any modifications then no performance penalty is paid. See Operation hooks for persistent models (intent-based hooks) #403 item "5) prototype.updateAttributes and data modified by hooks" and Operation hooks for persistent models (intent-based hooks) #403 (comment)

Here is my proposal: add a new method called e.g. prototype.update, mapped to POST /{models}/:id. This new method will perform a full update (replace) of all properties and thus set ctx.instance. This new method should become the new default to use when one wants to update the model instance (e.g. via $save() in Angular, see strongloop/loopback-sdk-angular#125 (comment)), while prototype.updateAttributes will be left for advanced scenarios only.

I'm thinking it makes sense to propagate an operation object as part of the context as a generic 'stash' for keeping state between before and after:

+1, thought I would use a different property name than "operation".

@fabien please note that your code contains a race condition: it's possible that the list of models returned by Model.find({where}) is different from the list of models deleted by Model.deleteAll(where), because a third party may modify relevant model instances in the small window between these two database queries. There are two solutions:

1. In the "before delete" hook, convert the arbitrary where query into an id-based query. Perform Model.find and then build a query using the returned ids. In this case you don't need to pass any data between hooks, because the list of ids can be easily extracted from the where property.
2. Drop "before delete" hook and rework the "after delete" hook to perform a full scan: find all instances that still exist in the database, compare it to the list of files, and then remove any extra files. Another advantage of this solutions is that if some files cannot be (temporarily) removed from the disk, they will be eventually removed later. again, you don't need ctx.operation.

[fabien]

@bajtos having prototype.update as the new default would be a huge breaking change - don't do it, please. Yes, updateAttributes performs a partial update, so data is not complete, however, the instance would be - that's the basic premise of it.

Any thoughts on the state property name (now called 'operation')?

Thanks for the pointers on my example:

1. how would this be different from passing along the instances as opposed to the ids of them? I gather either instances or ids from the same where condition, so I don't see where the difference would be.
2. seems very wasteful, as I would have to map all the files on disk to what's in the db - this could mean comparing /finding thousands of entries first.