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

Seems to be a code merge done by mistake.

change def self.primary_key to self.primary_key

change def self.primary_key to self.primary_key

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)`

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

of using +inverse_of: false+ option. Changing the documentation and
adding a CHANGELOG entry for the automatic inverse detection feature.

When removing records from a `has_many` association it used
the `primary_key` defined on the association.

Our test suite didn't fail because on all occurences of `:primary_key`,
the specified column was available in both tables. This prevented the
code from raising an exception but it still behaved badly.

I added a test-case to prevent regressions that failed with:

```
  1) Error:
HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL
```

According to
https://github.com/rails/rails/blob/b601399b72ab56cc01368f02615af99f45d1
4f02/activerecord/lib/active_record/counter_cache.rb#L14, u can pass
more then one association to the `reset_counters` method.

the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.

When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:

With the model

  class Topic
    alias_attribute :heading, :title
  end

The call

  Topic.where(heading: 'The First Topic')

should yield the same result as

  Topic.where(title: 'The First Topic')

This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.

This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.

Github #7839

*Godfrey Chan*

See #9869 and #9929.

The problem arises from the following example:

    class Project < ActiveRecord::Base
      scope :completed, -> { where completed: true }
    end

    class MajorProject < Project
    end

When calling:

    MajorProject.where(tasks_count: 10).completed

This expands to:

    MajorProject.where(tasks_count: 10).scoping {
      MajorProject.completed
    }

However the lambda for the `completed` scope is defined on Project. This
means that when it is called, `self` is Project rather than
MajorProject. So it expands to:

    MajorProject.where(tasks_count: 10).scoping {
      Project.where(completed: true)
    }

Since the scoping was applied on MajorProject, and not Project, this
fails to apply the tasks_count condition.

The solution is to make scoping apply across STI classes. I am slightly
concerned about the possible side-effects of this, but no tests fail and
it seems ok. I guess we'll see.

fixes #10016

PR #5210 added a Friendship model to illustrate a bug, but in doing so
created a confusing structure because both belongs_to declarations in
Friendship referred to the same side of the join. The new structure
maintains the integrity of the bug test while changing the follower
relationship to be more useful for other testing.

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`.

Closes #9110

It cannot find subclass because all classes are loaded automatically
when it needs.

closes #9201

Allow store accessors to be overrided like other attribute methods,
e.g.:

    class User < ActiveRecord::Base
      store :settings, accessors: [ :color, :homepage ], coder: JSON

      def color
        super || 'red'
      end
    end

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

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.

This reverts commit 4e05bfb8.

Reason: BlankTopic#blank? should not be removed to check that dynamic finder with a bang can find a model that responds to `blank?`

The native JSON library bypasses the `to_json` overrides in
active_support/core_ext/object/to_json.rb by calling its native
implementation directly. However `ActiveRecord::Store` uses a
HWIA so `JSON.dump` will call our `to_json` instead with a
`State` object for options rather than a `Hash`. This generates
a warning when the `:encoding`, `:only` & `:except` keys are
accessed in `Hash#as_json` because the `State` object delegates
unknown keys to `instance_variable_get` in its `:[]` method.

Workaround this warning in the test by using a custom coder that
calls `ActiveSupport::JSON.encode` directly.

Suggested by @dhh.

It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.