The `read_attribute` method always returns the primary key when asked to
read the `id` attribute, even if the primary key isn't named `id`, and
even if another attribute named `id` exists.

For the `inspect`, `attribute_for_inspect` and `pretty_print` methods,
this behaviour is undesirable, as they're used to examine the internal
state of the record. By using `_read_attribute` instead, we'll get the
real value of the `id` attribute.

Use column definition with `primary_key: true` instead.

The delegation methods to named scope are defined when `method_missing`
is invoked on the relation.

Since #29301, the receiver in the named scope is changed to the relation
like others (e.g. `default_scope`, etc) for consistency.

Most named scopes would be delegated from relation by `method_missing`,
since we don't allow scopes to be defined which conflict with instance
methods on `Relation` (#31179). But if a named scope is defined with the
same name as any method on the `superclass` (e.g. `Kernel.open`), the
`method_missing` on the relation is not invoked.

To address the issue, make the delegation methods to named scope is
generated in the definition time.

Fixes #34098.

`topic` and `reply` belongs_to associations on `SillyReply` are defined
with the same `foreign_key` (`parent_id`) and `counter_cache`
(`replies_count`) columns.
This would cause unintentional side-effect (e.g. saving `SillyReply`
object would cause double increment `replies_count`), so it is better to
avoid that side-effect.

Since 213796fb, bind params are used for IN clause if enabled prepared
statements.

Unfortunately, most adapter modules have a limitation for # of bind
params (mysql2 65535, pg 65535, sqlite3 250000). So if eager loading
large number of records at once, that query couldn't be sent to the
database.

Since eager loading/preloading queries are auto-generated by Active
Record itself, so it should be worked regardless of large number of
records like as before.

Fixes #33702.

Since fe9547b6, numericality validator would parse raw value only when a
value came from user to work type casting to a value from database.

But that was caused a regression that the validator would work against
getter value instead of parsed raw value, a getter is sometimes
customized by people. #33550

There we never guarantees that the value before type cast was going to
the used in this validation (actually here is only place that getter
value might not be used), but we should not change the behavior unless
there is some particular reason.

The purpose of fe9547b6 is to work type casting to a value from
database. We could achieve the purpose by using `read_attribute`,
without using getter value.

Fixes #33550.

What?
From now on when `accepts_nested_attributes_for` defined and `extend` option
added the overwritten `build` method being called.

[Alireza Bashiri, Martins Polakovs]

Since #29301, delegating to klass methods in the `scope` block would
cause extra scoping by the receiver itself. The extra scoping would
always override intermediate scoping like `unscoped` and caused the
regression #33387. To keep the original scoping behavior, should avoid
the extra scoping in the `scope` block.

Fixes #33387.

Currently, column aliases which is used for eager loading are calculated
before constructing all table aliases in FROM clause.

`JoinDependency#join_constraints` constructs table aliases for `joins`
first, and then always re-constructs table aliases for eager loading.

If both `joins` and eager loading are given a same table association,
the re-construction would cause the discrepancy between column aliases
and table aliases.

To avoid the discrepancy, the column aliases should be calculated after
all table aliases are constructed.

Fixes #30603.

`touch` option was added to `increment!` (#27660) and `update_counters`
(#26995). But that option behaves inconsistently with
`Persistence#touch` method.

If `touch` option is passed attribute names, it won't update
update_at/on attributes unlike `Persistence#touch` method.

Due to changed from `Persistence#touch` to `increment!` with `touch`
option, #31405 has a regression that `counter_cache` with `touch` option
which is passed attribute names won't update update_at/on attributes.

I think that the inconsistency is not intended. To get back consistency,
ensure that `touch` option updates update_at/on attributes.

In `_create_record`, explicit `transaction` block requires rollback
handling manually when `insert_record` is failed.

We need to handle it in `_create_record`, not in `insert_record`, since
our test cases expect a record added to target and returned even if
`insert_record` is failed,

Closes #31488.

Follow up of #32952.

- Fixes #32940

Since #31405, using `#increment!` with touch option instead of `#touch`
to touch belongs_to association if counter cache is enabled. It caused
the regression since `#increment!` won't invoke after_touch callbacks
even if touch option is given.
To fix the regression, make `#increment!` invokes after_touch callbacks
if touch option is given.

Fixes #31559.
Fixes #32408.

On belongs_to with `touch: true` association, unassigned object is
caused touching, but assigned object is not touched.

And also, if primary key is customized, it will touch against the wrong
target looked up by the customized key as primary key.

This change ensures correctly touching consistently between assigning
and unassigning.

* Rollback parent transaction when children fails to update

Rails supports autosave associations on the owner of a `has_many`
relationship. In certain situation, if the children of the association
fail to save, the parent is not rolled back.

```ruby
class Employee < ActiveRecord::Base
end

class Company < ActiveRecord::Base
  has_many(:employees)
end

company = Company.new
employee = company.employees.new
company.save
```

In the previous example, if the Employee failed to save, the Company
will not be rolled back. It will remain in the database with no
associated Employee.

I expect the `company.save` call to be atomic, and either create all or
none of the records.

The persistance of the Company already starts a transaction that nests
it's children. However, it didn't track the success or failure of it's
children in this very situation, and the outermost transaction is not
rolled back.

This PR makes the change to track the success of the child insertion and
rollback the parent if any of the children fail.

* Change the test to reflect what we expect

Once #32862 is merged, rolling back a record will rollback it's state to match
the state before the database changes were applied

* Use only the public API to express the tests

* Refactor to avoid reassigning saved for nested reflections

[Guillaume Malette + Rafael Mendonça França]

`becomes` creates new object and copies attributes from the receiver. If
new object has mutation tracker which is created in `after_initialize`,
it should be cleared since it is for discarded attributes.

But if the receiver doesn't have mutation tracker yet, it will not be
cleared properly.

It should be cleared regardless of whether the receiver has mutation
tracker or not.

Fixes #32867.

Adds test case for failing issue

Moves set_value back to protected

Follow up of #32514.

This fixes a bug with building an object that has multiple
`has_many :through` associations through the same object.
Previously, when building the object via .new, the intermediate
object would be created instead of just being built.

Here's an example:
Given a GameBoard, that has_one Owner and Collection through Game.
The following line would cause a game object to be created in the
database.

    GameBoard.new(owner: some_owner, collection: some_collection)

Whereas, if passing only one of those associations into `.new` would
cause the Game object to be built and not created in the database.

Now the above code will only build the Game object, and not save it.

Fix deprecation warnings from with_lock

The receiver in a scope was changed from `klass` to `relation` itself
for all scopes (named scope, default_scope, and association scope)
behaves consistently.

In addition. Before 5.2, if both an AR model class and a Relation
instance have same named methods (e.g. `arel_attribute`,
`predicate_builder`, etc), named scope doesn't respect relation instance
information.

For example:

```ruby
class Post < ActiveRecord::Base
  has_many :comments1, class_name: "RecentComment1"
  has_many :comments2, class_name: "RecentComment2"
end

class RecentComment1 < ActiveRecord::Base
  self.table_name = "comments"
  default_scope { where(arel_attribute(:created_at).gteq(2.weeks.ago)) }
end

class RecentComment2 < ActiveRecord::Base
  self.table_name = "comments"
  default_scope { recent_updated }
  scope :recent_updated, -> { where(arel_attribute(:updated_at).gteq(2.weeks.ago)) }
end
```

If eager loading `Post.eager_load(:comments1, :comments2).to_a`,
`:comments1` (default_scope) respects aliased table name, but
`:comments2` (using named scope) may not work correctly since named
scope doesn't respect relation instance information. See also 801ccab2.

But this is a breaking change between releases without deprecation.
I decided to bring back private class methods accessibility in named
scope.

Fixes #31740.
Fixes #32331.

Add a prefix option to ActiveRecord::Store.store_accessor and
ActiveRecord::Store.store. This option allows stores to have identical keys
with different accessors.

This is an alternative of #31877 to fix #31876 caused by #28808.

This issue was caused by a combination of several loose implementation.

* finding automatic inverse association of polymorphic without context (caused by #28808)
* returning `klass` even if `polymorphic?` (exists before #28808)
* loose verification by `valid_inverse_reflection?` (exists before #28808)

This makes `klass` raise if `polymorphic?` not to be misused.
This issue will not happen unless polymorphic `klass` is misused.

Fixes #31876.
Closes #31877.

3acc5d6e was changed the order of scope evaluation from through scope to
the association's own scope to be prioritized over the through scope.
But the sorting order will be prioritized that is evaluated first. It is
unintentional effect, association scope's sorting order should be
prioritized as well.

Fixes #32008.

Closes #31998

Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.

This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?

When removing a record from a has many through association, the counter
cache was being updated even if the through record halted the callback
chain and prevented itself from being destroyed.

Currently reflections keeps the order when first added even if when
redefining association. As a result of the order, redefining through
association which use newly added association will raise
`HasManyThroughOrderError`. We need to redefine reflection order as well
when redefining association.

Fixes #31068.

This is a regression test for #27864.

update_attribute previously stopped execution, before saving and before
running callbacks, if the record's attributes hadn't changed. [The
documentation](http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-update_attribute)
says that "Callbacks are invoked", which was not happening if the
persisted attributes hadn't changed.