In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.

There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)

[Melanie Gilman & Sean Griffin]

follow up for #17052

has_many definitions with "name" as singular and as plural e.g.
  has_many :welcome_posts_with_comment
  has_many :welcome_posts_with_comments

Ruby mentions it with:

lib/active_record/associations/builder/collection_association.rb:65:
  warning: method redefined; discarding old welcome_posts_with_comment_ids
lib/active_record/associations/builder/collection_association.rb:65:
  warning: previous definition of welcome_posts_with_comment_ids was here
lib/active_record/associations/builder/collection_association.rb:75:
  warning: method redefined; discarding old welcome_posts_with_comment_ids=
lib/active_record/associations/builder/collection_association.rb:75:
  warning: previous definition of welcome_posts_with_comment_ids= was here

In order to remove duplication with joining arel where constraints with
`AND`, all constraints on `build_arel` are collapsed into one head node: `Arel::Nodes::And`

Closes: #11963

This reverts commit 70d6e16f, reversing
changes made to ea4db3bc.

Seems to be a code merge done by mistake.

Closes #11248.

For example, you need to change this:

  class Author < ActiveRecord::Base
    has_many :posts
    has_many :taggings, :through => :posts
  end

  class Post < ActiveRecord::Base
    has_one :tagging
    has_many :taggings
  end

  class Tagging < ActiveRecord::Base
  end

To this:

  class Author < ActiveRecord::Base
    has_many :posts
    has_many :taggings, :through => :posts, :source => :tagging
  end

  class Post < ActiveRecord::Base
    has_one :tagging
    has_many :taggings
  end

  class Tagging < ActiveRecord::Base
  end

The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.

There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.

because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).

Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.

Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.

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.

now everything is converted to the new style, this is not needed

Don't use this:

    scope :red, where(color: 'red')
    default_scope where(color: 'red')

Use this:

    scope :red, -> { where(color: 'red') }
    default_scope { where(color: 'red') }

The former has numerous issues. It is a common newbie gotcha to do
the following:

    scope :recent, where(published_at: Time.now - 2.weeks)

Or a more subtle variant:

    scope :recent, -> { where(published_at: Time.now - 2.weeks) }
    scope :recent_red, recent.where(color: 'red')

Eager scopes are also very complex to implement within Active
Record, and there are still bugs. For example, the following does
not do what you expect:

    scope :remove_conditions, except(:where)
    where(...).remove_conditions # => still has conditions

See the CHANGELOG for details.

Fixes #950.

This reverts commit c99d507f.

Fix creation of has_many through records with custom primary_key option on belongs_to [#2990 state:resolved]

Verify that creating a has_many through record where there is a default_scope on the join model works correctly (creates the join record with the default scope applied)

Verify that creating a has_many through record where there is a default_scope on the join model works correctly (creates the join record with the default scope applied)

Support for :primary_key option on the source reflection of a through association, where the source is a has_one or has_many