I'm not to happy with having to have the before_batch there. But I didn't now how to do it without it.

Alright, so, I think we need to have both the old behavior and the new behavior as options. There are two reasons:

1. you can use cascade_destroy on an update action, which would be doable after the action
2. you can defer the constraints that would cause a foreign key error, as a performance improvement.

Alright, so, I think we need to have both the old behavior and the new behavior as options. There are two reasons:

1. you can use `cascade_destroy` on an update action, which would be doable after the action

2. you can defer the constraints that would cause a foreign key error, as a performance improvement.

Sounds good, one more thing though. I stumbled upon this not because of a foreign key error but because it would hit this line

Ohhhhh right. So the right answer here is also a bit frustrating to implement probably.

If the action is a destroy action, we should try to do it without loading data actually.

What that looks like is:

• If the relationship filter has no parent references and the relationship is not a many_to_many (I think this doesn't support many to many anyway)
  • then we extract the source_attribute, and construct a query against the destination for the specific id matches that exist plus the relationship.filter
  • unless no_attributes? true in which case we just use the query as is

Otherwise for destroy actions they must use the new before_batch behavior.

Ohhhhh right. So the right answer here is also a bit frustrating to implement probably.

If the action is a destroy action, we should try to do it without loading data actually.

What that looks like is:

* If the relationship filter has no parent references and the relationship is not a many_to_many (I think this doesn't support many to many anyway)
  
  * then we extract the source_attribute, and construct a query against the destination for the specific id matches that exist plus the relationship.filter
  * unless `no_attributes? true` in which case we just use the query as is

Otherwise for destroy actions they must use the new before_batch behavior.

I think that is pretty much what it is doing, isn't it? So in the error case we just need to check if we are in the after_action part of a a destroy action and if so return an error?

lol. Yep, sorry. Was early when I was first responding, hadn't had my coffee yet.

So I think the only thing needed here is to make this behavior opt-out, but opting out would raise an error if it gets to that error case and is an after action as you mentioned.

Ready to go?

🚀 Thank you for your contribution! 🚀