Previous version (after commit 3103296a61709e808aa89c3d37cf22bcdbc5a675) was generating wrong SQL for Oracle when calling exists? method on HABTM association.
otherwise when using external ActiveRecord adapters (e.g. Oracle) database_statements might be loaded before active_support/core_ext/module/deprecation which results in NoMethodError (commit 60cf65def805995bcca184c40b44bb01d86a48aa added "deprecate" call to database_statements.rb)
* Use :dependent => :nullify (or don't specify :dependent) if you want to prevent the existing associated object from being deleted
* Use has_many if you actually want multiple associated objects
* Explicitly set the foreign key if, for some reason, you really need to have multiple objects associated with the same has_one. E.g.
previous = obj.assoc
obj.create_assoc
previous.update_attributes(:obj_id => obj.id)
This required changing the code to keep the association proxy for a belongs_to around, despite its target being nil. Which in turn required various changes to the way that stale target checking is handled, in order to support various edge cases (loaded target is nil then foreign key added, foreign key is changed and then changed back, etc). A side effect is that the code is nicer and more succinct.
Note that I am removing test_no_unexpected_aliasing since that is basically checking that the proxy for a belongs_to *does* change, which is the exact opposite of the intention of this commit. Also adding various tests for various edge cases and related things.
Phew, long commit message!
* jonleighton/association_fixes:
Rename AssociationReflection#primary_key_name to foreign_key, since the options key which it relates to is :foreign_key
Support for :counter_cache on polymorphic belongs_to
Refactor BelongsToAssociation to allow BelongsToPolymorphicAssociation to inherit from it
Specify the STI type condition using SQL IN rather than a whole load of ORs. Required a fix to ActiveRecord::Relation#merge for properly merging create_with_value. This also fixes a situation where the type condition was appearing twice in the resultant SQL query.
Verify that when has_many associated objects are destroyed via :dependent => :destroy, when the parent is destroyed, the callbacks are run
Get rid of extra_conditions param from configure_dependency_for_has_many. I can't see a particularly plausible argument for this being used by plugins, and if they really want they can just redefine the callback or whatever. Note also that before my recent commit the extra_conditions param was completely ignored for :dependent => :destroy.
And owner_quoted_id can go too
Now we can drop-kick AssociationReflection#dependent_conditions into oblivion.
Refactor configure_dependency_for_has_many to use AssociationCollection#delete_all. It was necessary to change test_before_destroy in lifecycle_test.rb so that it checks topic.replies.size *before* doing the destroy, as afterwards it will now (correctly) be 0.
