On Mar 24, 11:33 am, Frederick Cheung <[email protected]> wrote: > > 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 > 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.
