This bug occurs when an attribute of an ActiveRecord model is an
ActiveRecord::Type::Integer type or a ActiveRecord::Type::Decimal type (or any
other type that includes the ActiveRecord::Type::Numeric module. When the value
of the attribute is negative and is set to the same negative value, it is marked
as changed.

Take the following example of a Person model with the integer attribute age:

    class Person < ActiveRecord::Base
      # age          :integer(4)
    end

The following will produce the error:

    person = Person.new(age: -1)
    person.age = -1
    person.changes
    => { "age" => [-1, -1] }
    person.age_changed?
    => true

The problematic line is here:

    module ActiveRecord
      module Type
        module Numeric
          ...

          def non_numeric_string?(value)
            # 'wibble'.to_i will give zero, we want to make sure
            # that we aren't marking int zero to string zero as
            # changed.
            value.to_s !~ /\A\d+\.?\d*\z/
          end
        end
      end
    end

The regex match doesn't accept numbers with a leading '-'.

Closes #17945

`db:test:prepare` still purges the database to always keep the test
database in a consistent state.

This patch introduces new problems with `db:schema:load`. Prior
to the introduction of foreign-keys, we could run this file against
a non-empty database. Since every `create_table` containted the
`force: true` option, this would recreate tables when loading the schema.

However with foreign-keys in place, `force: true` wont work anymore and
the task will crash.

/cc @schneems

To be possible to use a custom column name to save/read the polymorphic
associated type in a has_many or has_one polymorphic association, now users
can use the option :foreign_type to inform in what column the associated object
type will be saved.

Users should pass strings to queries instead of classes

[ci skp]

When running the following migration:

    change_table(:table_name) { |t| t/timestamps }

The following error was produced:

    wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps'

This is due to `arguments` containing an empty hash as its second
argument.

We will support only Ruby >= 2.1.

But right now we don't accept pull requests with syntax changes to drop
support to Ruby 1.9.

This reverts deprecations added in #13528.
The task is brought back for two reasons:
  1. Give plugins a way to hook into the test database initialization process
  2. Give the user a way to force a test database synchronization

While `test:prepare` is still a dependency of every test task, `db:test:prepare`
no longer hooks into it. This means that `test:prepare` runs before the schema
is synchronized. Plugins, which insert data can now hook into `db:test:prepare`.

The automatic schema maintenance can't detect when a migration is rolled-back,
modified and reapplied. In this case the user has to fall back to `db:test:prepare`
to force the synchronization to happen.

`.reflections` public API changed to return a String instead of a Symbol
as keys.

see commit 1f314884 and 6259e4e2

[fixes #16928]
[fixes #17610]

Also checked to make sure this does not affect foreign key constraints.
(It doesn't).

Fixes #12856
Closes #14088

on the joined assoiciation

Prior to this patch you'd end up with an error like:

```
ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)]
```

This method is still used by `update_all`

These appear to be implementation relics of times past. They duplicate
the logic in Relation, and are no longer used internally.

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]

The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.

This patch restores the priority to what we had before the refactoring.

/cc @sgrif

`add_reference` can very helpfully add a multi-column index when you use
it to add a polymorphic reference. However, the first column in the
index is the `id` column, which is less than ideal.

The [PostgreSQL docs][1] say:
> A multicolumn B-tree index can be used with query conditions that
> involve any subset of the index's columns, but the index is most
> efficient when there are constraints on the leading (leftmost)
> columns.

The [MySQL docs][2] say:
> MySQL can use multiple-column indexes for queries that test all the
> columns in the index, or queries that test just the first column, the
> first two columns, the first three columns, and so on. If you specify
> the columns in the right order in the index definition, a single
> composite index can speed up several kinds of queries on the same
> table.

In a polymorphic relationship, the type column is much more likely to be
useful as the first column in an index than the id column. That is, I'm
more likely to query on type without an id than I am to query on id
without a type.

[1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html

This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:

before:

    User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
    # => ActiveRecord::UnknownAttributeError: unknown attribute: name

after:

    User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
    # => ActiveRecord::UnknownAttributeError: unknown attribute on User: name

This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:

before:

    User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
    # => ActiveRecord::UnknownAttributeError: unknown attribute: name

after:

    User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
    # => ActiveRecord::UnknownAttributeError: unknown attribute on User: name

068f092c registered autosave callbacks
as `after_save` callbacks. This caused the regression described in #17209.

Autosave callbacks should be registered as `after_update` and
`after_create` callbacks, just like before.

This is a partial revert of 068f092c.

Fixes #17209.

Fix that a collection proxy could be cached before the save of the owner, resulting in an invalid proxy lacking the owner’s id.

Absent this fix calls like: owner.association.update_all to behave unexpectedly because they try to act on association objects where
owner_id is null.

more evidence here: https://gist.github.com/Empact/5865555
```
Active Record 3.2.13
-- create_table(:firms, {:force=>true})
   -> 0.1371s
-- create_table(:clients, {:force=>true})
   -> 0.0005s
1 clients. 1 expected.
1 clients updated. 1 expected.
```

```
Active Record 4.0.0
-- create_table(:firms, {:force=>true})
   -> 0.1606s
-- create_table(:clients, {:force=>true})
   -> 0.0004s
1 clients. 1 expected.
0 clients updated. 1 expected.
```

- middlware -> middleware

Honoring an overidden `rack.test` allows testing closed connection between
multiple requests. This is useful if you're working on database resiliency, to
ensure the connection is in the expected state from one request to another on
the same worker.

[ci skip]

it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK.  If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).

Closes #16907.

[Matthew Draper & Yves Senn]