* Fix undefined method `owners' for NullPreloader:Class

Fixing undefined method `owners' for
ActiveRecord::Associations::Preloader::NullPreloader:Class

* Use Ruby 1.9 hash format

Use Ruby 1.9 hash format

#24192

[Rafael Mendonça França + Ladislav Smola]

Changed id-writer to save join table records based on association primary key

If the through class has default scopes we should skip the statement
cache.

Closes #20745.

We deprecate the support for passing an argument to force reload in
6eae366d. That led to several
deprecation warning when running Active Record test suite.

This commit silence the warnings by properly calling `#reload` on the
association proxy or on the association object instead. However, there
are several places that `ActiveSupport::Deprecation.silence` are used as
those tests actually tests the force reload functionality and will be
removed once `master` is targeted next minor release (5.1).

This is to simplify the association API, as you can call `reload` on the
association proxy or the parent object to get the same result.

For collection association, you can call `#reload` on association proxy
to force a reload:

    @user.posts.reload   # Instead of @user.posts(true)

For singular association, you can call `#reload` on the parent object to
clear its association cache then call the association method:

    @user.reload.profile   # Instead of @user.profile(true)

Passing a truthy argument to force association to reload will be removed
in Rails 5.1.

The changes introduced to through associations in c80487eb were quite
interesting. Changing `relation.merge!(scope)` to `relation =
relation.merge(scope)` should in theory never cause any changes in
behavior. The subtle breakage led to a surprising conclusion.

The old code wasn't doing anything! Since `merge!` calls
`instance_exec` when given a proc, and most scopes will look something
like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing
the return value, it's a no-op. However, removing the `merge` causes
`unscope` to break.

While we're merging in the rest of the chain elsewhere, we were never
merging in `unscope` values, causing a breakage on associations where a
default scope was being unscoped in an association scope (yuk!). This is
subtly related to #20722, since it appears we were previously relying on
this mutability.

Fixes #20721.
Fixes #20727.

See #9683 for the reasons we switched to `distinct`.

Here is the discussion that triggered the actual deprecation #20198.

`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.

The old `test_create_bang_returns_falsy_when_join_record_has_errors` had
a missleading name and was a duplicate of
`test_save_should_not_raise_exception_when_join_record_has_errors`.

Since it had an assertion on the return value I renamed it accordingly
and got rid of the duplicate test.

In 1f006c an option was added called :class to allow passing anonymous
classes to association definitions. Since using :class instead of
:class_name is a fairly common typo even amongst experienced developers
this can result in hard to debug errors arising in raise_on_type_mismatch?

To fix this we're renaming the option from :class to :anonymous_class as
that is a more correct description of what the option is for. Since this
was an internal, undocumented option there is no need for a deprecation.

Fixes #19659

the newer method used for discriminating new records did not
use the older and more robust method used for instantiating
existing records, but did have a better post-check to ensure
the sublass was in the hierarchy. so move the descendants check
to find_sti_class, and then simply call find_sti_class from
subclass_from_attributes

now with fixed specs

Various behaviors needed by associations (such as creating the through
record) are lost when `where` is called, since we stop having a
`CollectionProxy` and start having an `AssociationRelation` which does
not contain this behavior. I *think* we should be able to rm
`AssociationRelation`, but we have tests saying the changes required to
do that would be bad (Without saying why. Of course. >_>)

Fixes #19073.

Since 3e30c5d4, it started ignoring the given error message. This commit
changes the behavior of AR::RecordNotSaved#initialize so that it no
longer loses the given error message.

`Computer` class needs to be require

See #17217 for more details

Callback order in Active Record objects are important. Users should not
define callbacks before the association definition or surprising
behaviours like the described at #3798 will happen. This callback order
dependency is documented at https://github.com/rails/rails/blob/31bfcdc77ca0d8cec9b5fe513bdc6f05814dd4f1/activerecord/lib/active_record/associations.rb#L1222-1227.

This reverts #15728.

Fixes #16620.

Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

If the through record gets created in an `after_create` hook that is
defined before the association is defined (therefore after its
`after_create` hook) get saved twice. This ensures that the through
records are created only once, regardless of the order of the hooks.

member = Member.new(club: Club.new)
member.save!

Before:

member.current_membership.club_id # => nil

After:

member.current_membership.club_id # => club's id

Since clear shouldn't fire callbacks the order doesn't
matter since it was never updated. Remove the portion
of this test that tests for order after clear.

This file is using this pattern already

[related #14116]

when destroying a record on a has_many :through association.
:destroy method has own counter_cache callbacks.

Fixes: #12242, #9517, #10240

original commit 89984419

Reverted here ec8ef1e1

side of a hm:t association along with preloading.

conditionals from the individual preloaded classes

and possibly different rules for finding those objects