We know the query will return exactly one row for each entry in the
`ids` array, so we can do all the limit/offset calculations on that
array, in advance.

I also split our new ordered-ids behaviour out of the existing
`find_some` method: especially with this change, the conditionals were
overwhelming the actual logic.

do not change the order of the result if the object was already ordered by the user via :order clause

Revert "Replace use of alias chains with prepend at core_ext/date and…

  not require mail file

  ```
  it added in this commit (https://github.com/rails/rails/commit/2a25c4ce6da6ea23ebdf44e7eb2d2441dbea20a1), now no warnings occur.
  ```

Update docs for ActiveRecord `serialize`

[ci skip]

For certain column types, using `serialize` is unnecessary, or the user
may get unexpected contents back from the DB adapter (which is handling
some basic deserialization for them). Call this out in the
documentation.

For background, see:

    https://gist.github.com/ernie/33f75f2294885b9806f9
    https://twitter.com/erniemiller/status/604262907442905090

Bundler 1.10 should work now!

Remove unused code.

Code was moved into the `assign` method.

Fix warning about ambiguous first argument

This reverts commit 81b42970.

This reverts commit 410d246b.

This reverts commit 9ff901bd.

Replace use of alias chains with prepend at core_ext/date and core_ext/time

See https://github.com/bundler/bundler/issues/3681

Updating the guides for Enumerable#pluck

Remove already defined methods in super class of ActionDispatch::Request class

Remove use of mocha from Active Model

Avoid E constant clashing with Minitest defined version.

Add Enumerable#pluck.

Fix the shadowing warning for `reflection`

Allows fetching the same values from arrays as from ActiveRecord associations.

This is a usability change to fix a quirk from our definition of partial
writes. By default, we only persist changed attributes. When creating a
new record, this is assumed that the default values came from the
database. However, if the user provided a default, it will not be
persisted, since we didn't see it as "changed". Since this is a very
specific case, I wanted to isolate it with the other quirks that come
from user provided default values. The number of edge cases which are
presenting themselves are starting to make me wonder if we should just
remove the ability to assign a default, in favor of overriding
`initialize`. For the time being, this is required for the attributes
API to not have confusing behavior.

We had to delete one test, since this actually changes the meaning of
`.changed?` on Active Record models. It now specifically means
`changed_from_database?`. While I think this will make the attributes
API more ergonomic to use, it is a subtle change in definition (though
not a backwards incompatible one). We should probably figure out the
right place to document this. (Feel free to open a PR doing that if
you're reading this).

/cc @rafaelfranca @kirs @senny

This is an alternate implementation of #19921.

Close #19921.

[Sean Griffin & Kir Shatrov]

This is a variant implementation of the changes proposed in #19914.
Unlike that PR, the change in behavior is isolated in its own class.
This is to prevent wonky behavior if a Proc is assigned outside of the
default, and it is a natural place to place the behavior required by #19921
as well.

Close #19914.

[Sean Griffin & Kir Shatrov]