Operational hook 'after delete' should receive id(s)

[fabien]

One of the main use-cases for this hook - and it's predecessor even deleted - is handling 'cascading deletes' (in NoSQL). However, unlike the soon-to-be-deprecated event, the new operational hook has no exact way to know what has been deleted, except for the where condition, which is not really helpful.

[JonnyBGod]

In truth this hook should really receive a copy of the object that was deleted (instance).

One other common use case is to remove related data from other services like files for instance.
For most of these use cases a simple object id is not enough as it probably relies on other stored information such as a path and/or a related model.

Without this information I am unable to grasp the utility for this hook.

[fabien]

@JonnyBGod I'll try to fix this

[JonnyBGod]

Ok. let me know if you need help.

[bajtos]

Let me explain why we are not passing the list of deleted ids or instances in the "after delete" hook. AFAIK, database drivers don't report back the list of id (nor full row data) in the response of a DELETE command. We could implement this at LoopBack side, but that would cause performance degradation for users that don't need this functionality.

IMO, this issue is not a problem in the "after delete" hook per se, but instead a problem of the current design of "deleteAll".

BTW note that if you delete a single model only, the id of the model can be obtained from the where query - see https://github.com/strongloop/loopback/blob/84c65de38ac24e012e3eb8c3f7fa281d565101da/lib/persisted-model.js#L1126-L1139. I think it makes sense to expose this method as a public Model API.

Here is my proposal how to solve this problem:

• Add an option that will change the behaviour of DELETEs to return the list of deleted ids or instances. I think it makes most sense to read this option from Model settings.
• Modify the implementation of "deleteById" and "deleteAll" to honour this new option and include the list of ids or instances in the "after delete" hook.
• Unless there is a driver that provides this functionality OOTB, we will have to always implement it at LoopBack side. In that case we can include the list of ids or instances in the "before delete" hook too.

Example model configurations:

// car.json
{
  "name": "Car",
  "options": {
    // query the full instance data
    "queryOnDelete": "full"
  }
}

// bar.json
{
  "name": "Bar",
  "options": {
    // query the id column only
    "queryOnDelete": "id"
  }
}

[raymondfeng]

From the view of practicality, relational DBs or MongoDB only tell you how many records are deleted by a DELETE from SQL statement or db.collection.remove(). There is no efficient way to provide the list of ids of deleted records.

[fabien]

@bajtos having those options makes sense - but perhaps we should focus on the lower-level first? Because you can already do this from the combination of before delete with after delete and the state property (TBD).

[bajtos]

@fabien You can already do this from the combination of before delete with after delete and the state property (TBD).

I am curious on what solution you come up with, because the one described in #481 (comment) is not correct as I explained in #481 (comment).

BTW I opened a new issue to track the hook state - see #484

[fabien]

@bajtos I must be missing something, because when I pass along the actual instances (or their ids) using hookState from a before delete to an after delete hook, how would I be executing the where query in the after delete hook? I would only operate on the ids/instances I gathered during before delete.