aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/associations/builder/has_and_belongs_to_many.rb
Commit message (Collapse)AuthorAgeFilesLines
* Removed support for deprecated `delete_sql` in associations.Neeraj Singh2013-07-031-1/+1
|
* Removed support for deprecated `insert_sql` in associations.Neeraj Singh2013-07-021-1/+1
|
* Removed deprecated options for assocationsNeeraj Singh2013-07-021-10/+0
| | | | | Deprecated options `delete_sql`, `insert_sql`, `finder_sql` and `counter_sql` have been deleted.
* Use method compilation for association methodsJon Leighton2012-08-101-1/+1
| | | | | | | | | 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.
* Unprivatise all the thingsJon Leighton2012-08-101-13/+11
| | | | | | Well, not all of them, but some of them. I don't think there's much reason for these methods to be private.
* Deprecate :finder_sql, :counter_sql, :insert_sql, :delete_sql.Jon Leighton2012-08-011-0/+10
|
* Revert "Remove :finder_sql, :counter_sql, :insert_sql, :delete_sql."Jon Leighton2012-08-011-1/+1
| | | | | | | | | This reverts commit 3803fcce26b837c0117f7d278b83c366dc4ed370. Conflicts: activerecord/CHANGELOG.md It will be deprecated only in 4.0, and removed properly in 4.1.
* Remove :finder_sql, :counter_sql, :insert_sql, :delete_sql.Jon Leighton2012-07-201-1/+1
|
* stop using class_attribute where methods/inheritance will suffice.Jon Leighton2012-07-131-2/+6
|
* Improve the derivation of HABTM assocation join table namesAndrew White2012-06-221-30/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* no longer need #delete_all_on_destroyJon Leighton2012-05-181-1/+1
|
* Fix #3672 again (dependent: delete_all perf)Jon Leighton2011-12-141-1/+1
|
* Destroy association habtm record before destroying the record itself. Fixes ↵Tomas D'Stefano2011-07-081-12/+10
| | | | issue #402.
* Removes the restriction on primary key when joining in a habtm && test that ↵Mohammad El-Abid2011-05-261-4/+0
| | | | it was properly removed
* Make clearing of HABTM join table contents happen in an after_destory callback.Murray Steele2011-03-231-12/+12
| | | | 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.
* Use proper objects to do the work to build the associations (adding methods, ↵Jon Leighton2011-02-211-0/+63
callbacks etc) rather than calling a whole bunch of methods with rather long names.