Closes #11026

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

This commit fixes a regression bug in which counter_cache columns
were not being updated correctly when newly created records were
being pushed into an assocation. EG:

    # this was fine
    @post.comment.create!

    # this was fine
    @comment = Comment.first
    @post.comments << @comment

    # this would not update counters
    @post.comments << Comment.create!

the primary key on an association will make sure that the corresponding
counter on the association is changed properly. Fixes #9722.

closes #9201

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 637a7d9d, reversing
changes made to 5937bd02.

Suggested by @dhh.

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

Fixes #8795

This test does not belong to has many associations test.

Consider this scenario:

    if params[:foo]
      conditions = { foo: true }
    end

    foos = Foo.where(conditions).order(:id)

When params[:foo] is nil, this would call:

    foos = Foo.where(nil).order(:id)

In this scenario, we want Foo.where(conditions) to be the same as calling
Foo.all, otherwise we'd get a "NoMethodError order for WhereChain".

Related to #8332.

examples:

  Model.where.not field: nil
  #=> "SELECT * FROM models WHERE field IS NOT NULL

  Model.where.like name: 'Jeremy%'
  #=> "SELECT * FROM models WHERE name LIKE 'Jeremy%'

this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330

Closes #5950

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.

Closes #8265

To perform a sum calculation over the array of elements, use to_a.sum(&block).

Please check the discussion in f9cb645d
for more context.

See issue #7950.

So that the scope may be a NullRelation and return a result without
executing a query.

Fixes #7928

Fixes #8102.

I couldn't find a nicer way to deal with this than delegate the call to
 #scope, which will be a NullRelation when we want it to be.

For example, the following should not run any query on the database:

Post.new.comments.where(body: 'omg').to_a # => []

Fixes #5215.

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.

The COUNT clause of a finder_sql relationship is being rewritten from
COUNT(*) to COUNT(table_name.*). This does not appear to be valid syntax
in MySQL:

```
mysql> SELECT COUNT( table_name.* ) FROM `table_name`;
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near '* ) FROM `table_name`' at line 1
```

This fixes the bug, as well as adding tests so we don't re-introduce
it in the future.

Fixes #3956.

It's not really a good idea to have this as a global config option. We
should allow people to specify the behaviour per association.

There will now be two new values:

* :dependent => :restrict_with_exception implements the current
  behaviour of :restrict. :restrict itself is deprecated in favour of
  :restrict_with_exception.
* :dependent => :restrict_with_error implements the new behaviour - it
  adds an error to the owner if there are dependent records present

See #4727 for the original discussion of this.

On reflection, it seems like a bit of a weird method to have on
ActiveRecord::Base, and it shouldn't be needed most of the time anyway.

This reverts commit 3803fcce.

Conflicts:
	activerecord/CHANGELOG.md

It will be deprecated only in 4.0, and removed properly in 4.1.

    User.order("name asc").order("created_at desc")
    # SELECT * FROM users ORDER BY created_at desc, name asc

This also affects order defined in `default_scope` or any kind of associations.

It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.

The code is moved to active_record_deprecated_finders.