Method compilation provides better performance and I think the code comes out cleaner as well. A knock on effect is that methods that get redefined produce warnings. I think this is a good thing. I had to deal with a bunch of warnings coming from our tests, though.
This reverts commit 3803fcc. Conflicts: activerecord/CHANGELOG.md It will be deprecated only in 4.0, and removed properly in 4.1.
Improve the derivation of HABTM join table name to take account of nesting. It now takes the table names of the two models, sorts them lexically and then joins them, stripping any common prefix from the second table name. Some examples: Top level models (Category <=> Product) Old: categories_products New: categories_products Top level models with a global table_name_prefix (Category <=> Product) Old: site_categories_products New: site_categories_products Nested models in a module without a table_name_prefix method (Admin::Category <=> Admin::Product) Old: categories_products New: categories_products Nested models in a module with a table_name_prefix method (Admin::Category <=> Admin::Product) Old: categories_products New: admin_categories_products Nested models in a parent model (Catalog::Category <=> Catalog::Product) Old: categories_products New: catalog_categories_products Nested models in different parent models (Catalog::Category <=> Content::Page) Old: categories_pages New: catalog_categories_content_pages Also as part of this commit the validity checks for HABTM assocations have been moved to ActiveRecord::Reflection One side effect of this is to move when the exceptions are raised from the point of declaration to when the association is built. This is consistant with other association validity checks.
… Fixes issue #402.
…t that it was properly removed
… callback. The old method of redefining destroy meant that clearing the HABTM join table would happen as long as the call to destroy succeeded. Which meant if there was a before_destroy that stopped the instance being destroyed using normal means (returning false, raising ActiveRecord::Rollback) rather than exceptional means the join table would be cleared even though the instance wasn't destroyed. Doing it in an after_destroy hook avoids this and has the advantage of happening inside the DB transaction too.
…ethods, callbacks etc) rather than calling a whole bunch of methods with rather long names.