909588d causes breakage if foreign keys are used

rubyonrails-core
1

909588d (for #6191 HABTM association is being destroyed before the before_destory callbacks are executed - Ruby on Rails - rails) reordered how destroy works with has and belongs to many.

The intent of the change is to ensure that before_destroy is called before any destroying happens which sounds right, but does it by removing the join table records after the owner is destroyed. This breaks all of my foreign key backed habtm associations since the foreign key won't allow deleting the owner while there are still join records pointing at it.

Was this an oversight? Having all the before_destroy callbacks run first definitely feels right, but I'd much prefer that this didn't clash with foreign keys (even if the default rails position isn't to use database constraints)

Fred

2

Yes, it is a bug.

Here is a very simply fix that considers both your scenario and the one in the original patch: https://gist.github.com/883459

Once we have a test case, I can apply and get this fixed. :smiley: Thanks for reporting!

3

Note: it seems google ignored my original post. Sorry if it ends up twice.

Yes, it is a bug.

Here is a very simple fix that considers your scenario and the one in the original patch: https://gist.github.com/883459

If you can provide a failing test, we can commit the fix + tests straight away. :smiley: Thanks for reporting!

4

Note: it seems google ignored my original post. Sorry if it ends up twice.

Yes, it is a bug.

Here is a very simple fix that considers your scenario and the one in the original patch:destroy_associations.diff · GitHub

Looks good!

If you can provide a failing test, we can commit the fix + tests straight away. :smiley: Thanks for reporting!

I'll see what I can cook up. I assume it would be preferable to come up with a test that enshrines the precise sequencing without actually requiring the table to have foreign keys in place

Fred

5

Since you guys are already working on it can I also get some feedback on this comment #5674 Regression: HABTM deletion fails when join table has foreign keys - Ruby on Rails - rails ?

(To repeat: patch solves the problem with the DB keys but any before_destroy callback on the model with HABTM assoc will see that assoc already emptied when fired)

6

>> Note: it seems google ignored my original post. Sorry if it ends up >> twice.

>> Yes, it is a bug.

>> Here is a very simple fix that considers your scenario and the one in >> the original patch:destroy_associations.diff · GitHub

> Looks good!

Since you guys are already working on it can I also get some feedback on this commenthttps://rails.lighthouseapp.com/projects/8994/tickets/5674-regression… ?

We should be ok there - The ticket/commit i linked to earlier adds tests ensuring that before_destroy fires before any destroying happens (although unfortunately in a way that introduces problems when foreign keys are in use). José's proposed fix won't break that

Fred

7

I'll see what I can cook up. I assume it would be preferable to come up with a test that enshrines the precise sequencing without actually requiring the table to have foreign keys in place

I've put something up at https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6629-habtm-destroy-deletes-record-before-associated-records

Fred