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. :D Thanks for reporting! On Mar 5, 6:40 pm, Frederick Cheung <[email protected]> wrote: > 909588d (forhttps://rails.lighthouseapp.com/projects/8994/tickets/6191) > 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
