It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.

Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.

Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.

remove extra spaces from deprecation message

```
# before
DEPRECATION WARNING:               Time columns will become time zone aware in Rails 5.1. This
              still causes `String`s to be parsed as if they were in `Time.zone`,
              and `Time`s to be converted to `Time.zone`.

              To keep the old behavior, you must add the following to your initializer:

                  config.active_record.time_zone_aware_types = [:datetime]

              To silence this deprecation warning, add the following:

                  config.active_record.time_zone_aware_types << :time
```

```
# after
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This
still causes `String`s to be parsed as if they were in `Time.zone`,
and `Time`s to be converted to `Time.zone`.

To keep the old behavior, you must add the following to your initializer:

    config.active_record.time_zone_aware_types = [:datetime]

To silence this deprecation warning, add the following:

    config.active_record.time_zone_aware_types << :time
```

Controller-wide fragment cache key prefixes

Add migration versioning via Migration subclasses

Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.

.. it also showed a deprecation warning, but we obviously needn't retain
that.

Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.

Application code should *not* do this.

If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.

The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.

Travis still don't have a updated version

Introduced in e56c6354, `CacheHelper#fragment_cache_key` is a duplicate of `ActionController::Caching::Fragments#fragment_cache_key`.

We now require the view to provide this method on its own (as with `view_cache_dependencies`); `ActionController::Caching::Fragments` exports its version as a `helper_method`.

Don't catch all NameError to reraise as ActionController::RoutingError

This reverts commit 6d5b1fdf.

`eager_load` and `references` can include hashes, which won't match up
with `references`

A test case has been added to demonstrate the problem

Update seeds.rb.tt

Rahm Emanuel doesn't deserve to be in Rails.

`ActiveRecord::Base#becomes` should copy the errors

This was changed in 421c81bd, as `exists?` blows up if you are eager
loading a polymorphic association, as it'll try to construct a join to
that table. The previous change decided to execute a `count` instead,
which wouldn't join.

Of course, the only time we actually need to perform a join on the eager
loaded values (which would perform a left outer join) is if they're
being referenced in the where clause. This doesn't affect inner joins.

Make Parameters#to_h and #to_unsafe_h return HWIA

There was a test remaining for PG only that was checking for an exact
limit clause

We currently generate an unbounded number of prepared statements when
`limit` or `offset` are called with a dynamic argument. This changes
`LIMIT` and `OFFSET` to use bind params, eliminating the problem.

`Type::Value#hash` needed to be implemented, as it turns out we busted
the query cache if the type object used wasn't exactly the same object.

This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`.
Doing this relied on AR internals, and was never officially supported
usage.

Fixes #22250.

This makes these two methods to be more inline with the previous
behavior of Parameters as Parameters used to be inherited from HWIA.

Fixes #21391

Some backends allow `LIMIT 1,2` as a shorthand for `LIMIT 1 OFFSET 2`.
Supporting this in Active Record massively complicates using bind
parameters for limit and offset, and it's trivially easy to build an
invalid SQL query by also calling `offset` on the same `Relation`.

This is a niche syntax that is only supported by a few adapters, and can
be trivially worked around by calling offset explicitly.

Add specific bug reporting guidelines to contributing.md [ci skip]

Add test cases for `#sanitize_sql_array` with named_bind_variables

This reverts commit 9712a7a1, reversing
changes made to 3e65c3d3.

Reverting because this caused test failures and while we have a followup
branch there is still one failure that happens randomly and isn't
straight forward to fix.

travel back

Controller generators should be creating IntegrationTest stubs instea…

Allows any Rake task to be run through `bin/rails` such as `bin/rails db:migrate`,
`bin/rails notes` etc.

The Rake tasks are appended to Rails' help output, and blend in as standard commands.

Prevent a 500 in the default controller scaffold