909588d (for https://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.
