The error message that we give today makes this error difficult to debug
if you receive it. I have no clue why we're printing the object ID of
the class (the commit doesn't give context), but I've left it as it was
deliberate.

When I originally reviewed the #20317, I believe these changes were
present, but it appears that it was later updated so that they were
removed. Since Travis hadn't re-run the build, this slipped through.

As described in the "Follow Coding Conventions" section in our
contribution guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions)
we favor `assert_not` over `refute`.

While we don't usually make stylistic changes on it's own I opted to do
it in this case. The reason being that test cases are usually copied as
a starting point for new tests. This results in a spread of `refute` in
files that have been using it already.

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.

thrown ActiveRecord::AssociationTypeMismatch when assigning a wrong value for a namespaced association

fixes #20541

raise ActiveModel::MissingAttributeError when trying to access a relationship without the foreign key attribute

fixes regression reported on #20253

ActiveRecord::Base#[] was not used cause of 8b954200

Unitialized polymorphic `belongs_to` associations raise an error while
attempting to reload, as they attempt to make an uncached reload, but
don't have a klass to fetch uncachedly. In this case, `loaded?` should
be `false` anyway.

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

Assert that counter_cache behaviour is not used on belongs_to or
has_many associations if the option is not given explicitly.

[fixes #18606]

Make belongs_to use touch over touch_later when running the callbacks.

Add more tests and small method rename

Thanks Jeremy for the feedback.

Deprecate `required` option in favor of `optional` for belongs_to.

`Computer` class needs to be require

See #17217 for more details

fixes #17495

Isolate access to @associations_cache and @aggregations cache to the Associations and Aggregations modules, respectively.

This includes replacing the `association_cache` accessor with a more
limited `association_cached?` accessor and making `clear_association_cache`
and `clear_aggregation_cache` private.

This reverts commit e84799d9, e31104c1 and e6ca8e2c

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.

The foreign_key could be `String` and just doing `owners_map[owner_key]`
could return `nil`.
To prevent this bug, we should `to_s` both keys if their types are
different.

Fixes #14734.

Follow up to af549a1a

Backport test from #14410

Prior to Rails 4.0.4 when touching a object which doesn't have timestamp
attributes (updated_at / updated_on) rails would still touch all
associations. After 73ba2c14 it updates
associations but rollsback because `touch` would return nil since
there's no timestamp attribute

 This is to ensure that they are not accidentally called by the app code.
 They are renamed to _create_record and _update_record respectively.
 Closes #11645

Dangerous association names conflicts include instance or class
methods already defined by `ActiveRecord::Base`.

Since Rails 4.0, we add an ORDER BY in the `first` method to ensure consistent
results among different database engines. But for singular associations this
behavior is not needed since we will have one record to return. As this
ORDER BY option can lead some performance issues we are removing it for singular
associations accessors.

Fixes #12623.

Fixes: #13445

removed unnecessary test case and improved test case for belongs_to having invalid  options