Delegation of some `Array` methods was removed in commit 9d79334a. That
change did add explicit delegation of a few methods that `Array` has but
which aren't on `Enumerable`.  However, a few non-mutation methods were
omitted.  This adds `Array` delegation of `#in_groups`, `#in_groups_of`,
`#shuffle` and `#split`.  This allows things like
`MyThing.all.in_groups_of(3) { ... }` to continue working as they did
before commit 9d79334a.

`#` was removed at f57092ad but this `#` is intentional.
e.g. https://github.com/rails/rails/blame/v5.0.0.beta2/activerecord/CHANGELOG.md#L1423-L1426

This was showing up as an H1. Fixing the indentation here fixes the codeblock.

Simply it is sufficient to override `can_perform_case_insensitive_comparison_for?`.

- Previously it used to show error message
    <"undefined method `limit_value' for {:title=>\"Rails\"}:Hash">

- Now it shows following error message.

    >> Post.where.not(name: 'DHH').or(name: 'Tenderlove')
    ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead.

- Fixes #23714.

- The change was added in #23099

When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.

    PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
	# => SELECT "price_estimates".* FROM "price_estimates"
         WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))

This is fixed to properly look for any records matching both type and id:

    PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
    # => SELECT "price_estimates".* FROM "price_estimates"
         WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
         OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))

Saw the `merge!` and had to prove to myself that the parent model's local_stored_attributes was not being changed when stored_attributes is called on a child model. Proved to be working as expected but this test is probably still useful to keep around.

[ci skip]

Previously if you used `t.foreign_key` twice within the same
`create_table` block using the same `to_table`, all statements except
the final one would fail silently. For example, the following code:

    def change
      create_table :flights do |t|
        t.integer :from_id, index: true, null: false
        t.integer :to_id,   index: true, null: false

        t.foreign_key :airports, column: :from_id
        t.foreign_key :airports, column: :to_id
      end
    end

Would only create one foreign key, on the column `from_id`.

This commit allows multiple foreign keys to the same table to be created
within one `create_table` block.

The author name was lost in the merge commit 6fedc7d5.

instead of loading the relation into memory

since starting with Rails 5.x(beta) we prefer to use rails as the replacement of rake commands, may be change log will be the same

In Rails 5, we're much more restrictive about when we do or don't cache
a prepared statement. In particular, we never cache when we are sending
an IN statement or a SQL string literal

However, in the case of Adequate Record, we are *always* sending a raw
SQL string, and we *always* want to cache the result.

Fixes #23507

/cc @tgxworld

This removes the following warnings.

```
activerecord/lib/active_record/relation/finder_methods.rb:252: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:258: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:268: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:274: warning: ambiguous first argument; put parentheses or a space even after `-' operator
```

This commit walks the reflection tree and builds the scope chain
functionally.  It also removes the chain cache since the cache doesn't
seem to have any impact on performance (I'd prefer to only cache at
proven bottlenecks)

When changing the PK for a record which has a uniqueness validation on
some other attribute, Active Record should exclude itself from the
validation based on the PK value stored on the DB (id_was) instead of
its new value (id).

  - Corrects an incorrect exception message when using accepts_nested_attributes_for
  - Removes rescue/reraise behavior introduced in #19077
  - Adds has_many & has_one, nested_attributes test case specifying the message that
    should be conveyed with an exception raised because one of the nested attributes provided is unknown

Follow up to #23508.

A return value of `schema_type` is used by:

1. primary key type: using as `symbol.inspect`
2. normal column type: using as `symbol.to_s`

It is better to return symbol.

With this addition, you can add a column into the table like:

```
  create_table(:numeric_types) do |t|
    t.numeric :foo, precision: 10, scale: 2, default: 2.0
  end
```

The result of the migration above is same with:

```
  create_table(:numeric_types) do |t|
    t.decimal :foo, precision: 10, scale: 2, default: 2.0
  end
```

Fixes #22980.

`require 'active_support/core_ext/benchmark'` was added by 4ecdf24b.
But currently unused anymore.

It appears first in `lib/active_record.rb`.

Follow up of https://github.com/rails/rails/commit/c9feea6c9ab4494b0cb0b8cf4316847854f65af6

This reverts commit 99801c6a.

Ultimately it doesn't matter whether `add_index` or `t.index` are used
in the schema dumper in any meaningful way. There are gems out there
which hook into the old behavior for things like indexing materialized
views. Since the reverted commit doesn't seem to add much benefit,
there's no reason for us to break these gems.

If you set the DATABASE_URL environment variable to `mydatabase` by accident, you end up getting a series of errors that are hard to trace. For example: 

```
warning: already initialized constant ActiveRecord::Base::OrmAdapter
```

Turns out the cascade of errors is due to the error raised by `.tr` being called on `nil`.

This commit makes sure that `scheme` is set before calling `.tr` on it. My previous iteration used `@uri.scheme.try(:tr, '-', '_')` but using the `&&` logical operator is a fair bit faster: http://stackoverflow.com/questions/26655032/try-vs-performance

With this change, the error message becomes much more understandable:

```
FATAL:  database "mydatabase" does not exist (ActiveRecord::NoDatabaseError)
```

https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html
https://dev.mysql.com/doc/refman/5.7/en/creating-spatial-indexes.html