Rails has abstract Reflection classes (`MacroReflection`,
`AssociationReflection` etc.) and concrete Reflection classes
(e.g. `HasManyReflection`, `HasOneReflection` etc.).
In many case `calculate_constructable` returns `true`, so
change `calculate_constructable` to always return `true` and
override this method if necessary.

I've gotten tripped up more than a few times on this, thinking that
using `belongs_to` with `touch: true` would trigger my after_save or
after_update callbacks. The same text is in the documentation for the
touch method itself, but I think its helpful to repeat it again here.
It might save people some time.

For reduce bootstrap queries in tests.

- Updated persistence documentation to make it clear that save and save! won't update a record if validation fails.
- Also fixed `update` method's documention to be uniform about this statement.
Fixes #20821

[ci skip]

[Vipul A M & pseidemann ]

    p PostgreSQLAdapter::OID::Money.precision
    # => 19

    p PostgreSQLAdapter::OID::Money.new.precision
    # => nil

This reverts commit ff835f90, reversing
changes made to c4d85dfb.

Reason: This broke the tests. We will add back after investigated.

Follow up to #22896.

`LOST_CONNECTION_ERROR_MESSAGES` was added by f3845822.
But currently unused from anywhere.

`SchemaMigration.drop_table` is only used in tests.
Simply we can use `drop_table if_exists: true`.

`ActiveRecord::ConnectionAdapters::SchemaStatements#columns` is defined
here as an interface method here. So changes to raise `NotImplementedError`
same as `tables`, `views` ...etc.

If `AR.primary_key` is called for a table who has composite primary key,
the method returns `nil`. This behavior sometimes generates invalid SQL.
The first time developers notice to invalid SQL is when they execute
SQL. This commit enables developers to know they are doing something
dangerous as soon as possible.

These methods are more expensive than the alternatives, and have strange semantics that are likely undesirable.

instead of loading relation

This line causes an error when executing the command: `rails db:drop db:create db:schema:load`

ActiveRecord::StatementInvalid: PG::SyntaxError: ERROR:  syntax error at or near "{"
LINE 1: ...NSERT INTO "schema_migrations" (version) VALUES (#{v}), (#{v...

@bogdan pointed out that a `loaded?` relation would not warn that the supplied
offset would be removed. This fixes that oversight.

https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834

Although this second argument is probably not widely used, and would be
ignored anyway in the loaded? case, this could protect callers from gotchas.

[Ben Woosley & Victor Kmita]

The commit which originally added this behavior did not consider that
doing `Subclass.new` does not actually populate the `type` field in the
attributes (though perhaps it should). We simply need to not use the
defaults for STI related things unless we are instantiating the base
class.

Fixes #23285.

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

Integer limit as a byte size was introduced from Rails 2.1.
`limit: 11` is not a byte size, but take care for backward-compatibility
with Rails 2.0 (a892af60). Integer limit out of range should be allowed
to raise by #6349. I think we should remove this backward-compatibility.

- We don't need the select scope added by user as we only want to max
  timestamp and size of the collection. So we already know which columns
  to select.
- Additionally having user defined columns in select scope blows the cache_key
  method with PostGreSQL because it needs all `selected` columns in the group_by
  clause or aggregate function.
- Fixes #23038.

Fixes #23209

- 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

Because of the changes in #22967 the assumption in #18907 is no longer
true because the internal metadata feature for Active Record requires
a working environment.

This fixes incorrect assumptions made by e991c7b8 that we can assume the
DB is already casting the value for us. The enum type needs additional
information to perform casting, and needs a subtype.

I've opted not to call `super` in `cast`, as we have a known set of
types which we accept there, and the subtype likely doesn't accept them
(symbol -> integer doesn't make sense)

Close #23190

Instance level writers can have an impact on how the Active Model /
Record objects are saved.  Specifically, they can be used to bypass
validations.  This is a problem if mass assignment protection is
disabled and specific attributes are passed to the constructor.

CVE-2016-0753

When updating an associated record via nested attribute hashes the
reject_if proc could be bypassed if the _destroy flag was set in the
attribute hash and allow_destroy was set to false.

The fix is to only short-circuit if the _destroy flag is set and the
option allow_destroy is set to true. It also fixes an issue where
a new record wasn't created if _destroy was set and the option
allow_destroy was set to false.

CVE-2015-7577