On Mar 23, 6:18 pm, José Valim <[email protected]> wrote: > 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 >
Looks good! > If you can provide a failing test, we can commit the fix + tests > straight away. :D 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 > 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.
