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

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

Seems to be a code merge done by mistake.

Closes #11248.

Method `delete_all` should not be invoking callbacks and this
feature was deprecated in Rails 4.0. This is being removed.
`delete_all` will continue to honor the `:dependent` option. However
if `:dependent` value is `:destroy` then the default deletion
strategy for that collection will be applied.

User can also force a deletion strategy by passing parameter to
`delete_all`. For example you can do `@post.comments.delete_all(:nullify)`

fixes #10016

This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.

In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.

The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:

  default_scope.merge(association_scope)

If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')

Now, the RHS of the merge is left alone.

Fixes #8990

This reverts commit 637a7d9d, reversing
changes made to 5937bd02.

This commit fixes reported issue #7630 in which counter
caches were not being updated properly when replacing
has_many_through relationships

This reverts commit abf8de85.
We should take a deeper look to those cases flat_map doesn't do deep
flattening.

irb(main):002:0> [[[1,3], [1,2]]].map{|i| i}.flatten
=> [1, 3, 1, 2]
irb(main):003:0> [[[1,3], [1,2]]].flat_map{|i| i}
=> [[1, 3], [1, 2]]

Patches `CollectionAssociation#count` to return 0 without querying
if the parent record is new. Consider the following code:

    class Account
      has_many :dossiers
    end

    class Dossier
      belongs_to :account
    end

    a = Account.new
    a.dossiers.build

    # before patch
    a.dossiers.count
    # SELECT COUNT(*) FROM "dossiers" WHERE "dossiers"."account_id" IS NULL
    # => 0

    # after
    a.dosiers.count # fires without sql query
    # => 0

Fixes #1856.

If assigning to a has_many :through collection against an unsaved
object using the collection=[<array_of_items>] syntax, the join models
were not properly created, previously.