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
Since you guys are already working on it can I also get some feedback on
this comment
https://rails.lighthouseapp.com/projects/8994/tickets/5674-regression-habtm-deletion-fails-when-join-table-has-foreign-keys#ticket-5674-10
?
(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)