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

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

[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

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

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.

And improve changelongs.

[ci skip]

This reverts commit 9f3730a5, reversing
changes made to 2637fb75.

There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.

instead of loading relation

Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch

We found that inserting all 600 schema_migrations for our mid-sized app takes about a minute on a cloud based CI environment.

I assume that the original code did not use multi-row-insert because SQLite3 was not supporting the syntax back then,
but it's been supported since 3.7.11: http://www.sqlite.org/releaselog/3_7_11.html

- Using `references` or `belongs_to` in migrations will always add index
  for the referenced column by default, without adding `index:true` option
  to generated migration file.
- Users can opt out of this by passing `index: false`.
- Legacy migrations won't be affected by this change. They will continue
  to run as they were before.
- Fixes #18146

Closes #21986.

This makes it possible to write custom types that define a different
mapping for STI columns.

Changed options for find_each and variants to have options start/finish instead of start_at/end_at based on comments
at https://github.com/rails/rails/pull/12257#issuecomment-74688344

This reverts commit 224eddfc, reversing
changes made to 9d681fc7.

When merging the pull request, I misunderstood `has_secure_token` as declaring a model
has a token from birth and through the rest of its lifetime.

Therefore, supporting conditional creation doesn't make sense. You should never mark a
model as having a secure token if there's a time when it shouldn't have it on creation.

Example:

    create_table :posts do |t|
      t.datetime :published_at, default: -> { 'NOW()' }
    end

Closes #22584.

Closes #23021.

Pass through :if and :unless options from has_secure_token to the
generated before_create callback

[ci skip]

While the type definition is in Active Model the change of behavior will
be only user facing in Active Record so better to put the entry in its
changelog.

[ci skip]

In Pg and Sqlite3, `:text` and `:binary` have variable unlimited length.
But in MySQL, these have limited length for each types (ref #21591, #21619).
This change adds short-hand methods for each text and blob types.

Example:

    create_table :foos do |t|
      t.tinyblob   :tiny_blob
      t.mediumblob :medium_blob
      t.longblob   :long_blob
      t.tinytext   :tiny_text
      t.mediumtext :medium_text
      t.longtext   :long_text
    end

I realized that `first(2)`, etc. was unnecessarily querying for the
records when they were already preloaded. This was because
`find_nth_with_limit` can not know which `@records` to return because
it conflates the `offset` and `index` into a single variable, while
the `@records` only needs the `index` itself to select the proper
record.

Because `find_nth` and `find_nth_with_limit` are public methods, I
instead introduced a private method `find_nth_with_limit_and_offset`
which is called internally and handles the `loaded?` checking.

Once the `offset` argument is removed from `find_nth`,
`find_nth_with_limit_and_offset` can be collapsed into
`find_nth_with_limit`, with `offset` always equal to `offset_index`.

All uses of the `offset` are passing `offset_index`. Better to push
down the `offset` consideration into `find_nth`.

This also works toward enabling `find_nth_with_limit` to take
advantage of the `loaded?` state of the relation.

[ci skip]

This reverts commit 537ac7d6, reversing
changes made to 9c9c54ab.

Reason:
The way we preload associations will change the meaning of GROUP BY
operations. This is illustrated in the SQL generated by the added
test (failing on PG):

Association Load:
D, [2015-12-21T12:26:07.169920 #26969] DEBUG -- :   Post Load (0.7ms)  SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" = $1 GROUP BY posts.id ORDER BY SUM(comments.tags_count)  [["author_id", 1]]

Preload:
D, [2015-12-21T12:26:07.128305 #26969] DEBUG -- :   Post Load (1.3ms)  SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" IN (1, 2, 3) GROUP BY posts.id ORDER BY SUM(comments.tags_count)

During the `5.0.0.beta1` release, the CHANGELOGs got an entry like the
following:

```
* No changes.
```

It is kinda confusing as there are indeed changes after it. Not a
biggie, just a small pass over the CHANGELOGs.

[ci skip]

The changelog entry for ApplicationRecord was a bit confusing. Thank you
guys for helping me get it in a better shape.

[ci skip]