Before 29874cc4 the order values
would be deduplicated when the SQL query is generated, but now
it has to be eager.

This was added in 6223e206 to allow
`table_name_prefix`, `table_name_suffix`, and `pluralize_table_names` to
be injected instead of always being read from `ActiveRecord::Base`. It
was never documented, and after 336783ad
and 0c843640 setting it has no effect.

This is an alternative of #29722.

Before Rails 6.1, storing demodulized class name is supported only for
STI type by `store_full_sti_class` class attribute.

Now `store_full_class_name` class attribute can handle both STI and
polymorphic types.

Closes #29722.

See also #29601, #32048, #32148.

Related to #35210.

We sometimes use `select` to limit unused columns for performance.

For example, `GET /posts/1` (post detail) usually use (almost) all
columns, but `GET /posts` (post list) does not always use all columns
(e.g. use `id` and `title` for the list view, but `body` is not used).

If an association is eager loaded, the limited `select` doesn't works as
expected, eager loading will load all columns on the model, plus also
load the `select` columns additionally. It works differently with
natural load and preload. It means that changing natural load or preload
to eager load (or vice versa) is unsafe.

This fixes eager loading that always load all columns (plus extra
`select` columns), to respect the `select` columns like as others.

```ruby
post = Post.select("UPPER(title) AS title").first
post.title # => "WELCOME TO THE WEBLOG"
post.body  # => ActiveModel::MissingAttributeError

# Rails 6.0 (ignore the `select` values)
post = Post.select("UPPER(title) AS title").eager_load(:comments).first
post.title # => "Welcome to the weblog"
post.body  # => "Such a lovely day"

# Rails 6.1 (respect the `select` values)
post = Post.select("UPPER(title) AS title").eager_load(:comments).first
post.title # => "WELCOME TO THE WEBLOG"
post.body  # => ActiveModel::MissingAttributeError
```

Someone had relied on the behavior that preloading with a given scope,
but the behavior has lost in #35496 to fix the minor bug that unloading
through association.

Basically we don't guarantee the internal behavior, but the bugfix can
be achieved without any breaking change, so I've restored the lost
functionality.

Fixes #36638.
Fixes #37720.

Looking at the history this is holdover from the pre-pool manager and
changes made by Shopify. The tests pass without it and we've had enough
changes that it doesn't appear necessary anymore.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

If we enter a `connected_to` block and call `establish_connection` like
the test added here we need to ensure that `shard: current_shard` is passed
to the handler, otherwise the connection will be established on
`default` not on `shard_one`.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

Follow up of #40000.

In #40000, `eager_load(:general_categorizations, :general_posts)` works,
but `eager_load(:general_posts, :general_categorizations)` doesn't work
yet.

This implements the deduplication for the case of reversed eager loading
order.

In `connected_to` one of the deprecated arguments wasn't well tested so
the incorrect methods signature wasn't caught by the tests.

This change updates the caller when `connected_to` uses the database
key.

I've also cleaned up a few arguments that weren't necessary. Since
the handler methods set defaults for the `shard` key, we don't need to
pass that in `establish_connection` when not using the sharding API.

This change ensures that the connection methods are using kwargs instead
of positional arguments. This change may look unnecessary but we're
working on refactoring connection management to make it more robust and
flexible so the method signatures of the methods changed here will
continue to evolve and change.

This commit does not change any released public APIs. The `shard` and
`owner_name` arguments were added in 6.1 which is not released yet.
Using kwargs will allow these methods to be more flexible and not get
super ugly as we change their underlying behavior. The kwargs let us
support multiple non-positional arguments with default.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

This change renames the following:

* `current_pool_key` -> `current_shard`
* `default_pool_key` -> `default_shard`
* `pool_key` -> `shard`

Originally we had intended to name the `shard` as `pool_key` because
when we implemented the internal private API we weren't sure how it was
going to be used for sharding and wanted to implement behavior without
promising a public API. Now that we have a public API for sharding it's
better to use the same name everywhere rather than have one name for
private APIs and one name for public APIs. This should make
contributions and tracking down bugs easier in the future.

This PR doesn't require any deprecations because the sharding API is
unreleased and so is all the internal code that was using `pool_key`.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

I had found the issue while working on fixing #33525.

That is if duplicated association has a scope which has `where` with
explicit table name condition (e.g. `where("categories.name": "General")`),
that condition in all duplicated associations will filter the first one
only, other all duplicated associations are not filtered, since
duplicated joins will be aliased except the first one (e.g.
`INNER JOIN "categories" "categories_categorizations"`).

```ruby
class Author < ActiveRecord::Base
  has_many :general_categorizations, -> { joins(:category).where("categories.name": "General") }, class_name: "Categorization"
  has_many :general_posts, through: :general_categorizations, source: :post
end

authors = Author.eager_load(:general_categorizations, :general_posts).to_a
```

Generated eager loading query:

```sql
SELECT "authors"."id" AS t0_r0, ... FROM "authors"

-- `has_many :general_categorizations, -> { joins(:category).where("categories.name": "General") }`
LEFT OUTER JOIN "categorizations" ON "categorizations"."author_id" = "authors"."id"
INNER JOIN "categories" ON "categories"."id" = "categorizations"."category_id" AND "categories"."name" = ?

-- `has_many :general_posts, through: :general_categorizations, source: :post`
---- duplicated `through: :general_categorizations` part
LEFT OUTER JOIN "categorizations" "general_categorizations_authors_join" ON "general_categorizations_authors_join"."author_id" = "authors"."id"
INNER JOIN "categories" "categories_categorizations" ON "categories_categorizations"."id" = "general_categorizations_authors_join"."category_id" AND "categories"."name" = ? -- <-- filtering `"categories"."name" = ?` won't work
---- `source: :post` part
LEFT OUTER JOIN "posts" ON "posts"."id" = "general_categorizations_authors_join"."post_id"
```

Originally eager loading with join scope didn't work before Rails 5.2
(#29413), and duplicated through association with join scope raised a
duplicated alias error before alias tracking is improved in 590b045e.

But now it will potentially be got incorrect result instead of an error,
it is worse than an error.

To fix the issue, it makes eager loading to deduplicate / re-use
duplicated through association if possible, like as `preload`.

```sql
SELECT "authors"."id" AS t0_r0, ... FROM "authors"

-- `has_many :general_categorizations, -> { joins(:category).where("categories.name": "General") }`
LEFT OUTER JOIN "categorizations" ON "categorizations"."author_id" = "authors"."id"
INNER JOIN "categories" ON "categories"."id" = "categorizations"."category_id" AND "categories"."name" = ?

-- `has_many :general_posts, through: :general_categorizations, source: :post`
---- `through: :general_categorizations` part is deduplicated / re-used
LEFT OUTER JOIN "posts" ON "posts"."id" = "categorizations"."post_id"
```

Fixes #32819.

Follow up to #38086.

User assigned nil is type casted by #38086, but loaded nil from database
does not yet, this fixes that.

Directly `klass.new` is clear enough than factory methods.

It's no longer used since https://github.com/rails/rails/commit/5ce3e022ef136324d288fb493e0938e76a74981a

Removes the use of `ActiveRecord::AdvisoryLockBase` since it inherits
from `ActiveRecord::Base` and hence share module attributes that are defined in `ActiveRecord::Base`.
This is problematic because establishing connections through
`ActiveRecord::AdvisoryLockBase` can end up changing state of the default
connection handler of `ActiveRecord::Base` leading to unexpected
behaviors in a Rails application.

In the case of https://github.com/rails/rails/issues/39157,

Running migrations with `rails db:migrate:primary_shard_one` was not working as
the application itself defined the following

```
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to shards: {
    default: { writing: :primary },
    shard_one: { writing: :primary_shard_one }
  }
end
```

In the database migrate rake task, the default connection was
established with the database config of `primary_shard_one`. However,
the default connection was altered to that of `primary` because
`ActiveRecord::AdvisoryLockBase.establish_connection` ended up loading
`ApplicationRecord` which calls `connects_to shards:`. Since all we
really need here is just a normal database connection, we can avoid
accidentally altering the default connection handler state during the migration
by creating a custom connection handler used for retrieving a connection.

Currently, the file generated via the generator is pluralized
but the parent class is singluar.

example: bundle exec rails g scaffold Pet name:string --database=animals

The above command should generate: apps/models/animals_record.rb

but the pets model would inherit from: `AnimalRecord` as
`"animals".classify` would be `Animal`

This will throw the `uninitialized constant AnimalRecord Did you mean? AnimalsRecord`
error.

Regardless of whether doing implicit `create_with` or not, `sti_name` is
set by `ensure_proper_type`.

https://github.com/rails/rails/blob/11f54e12b992f6c8d29fd9bedd89ac438a928a2f/activerecord/lib/active_record/inheritance.rb#L289-L304

The purpose of the `create_with` is to suppress/override `type_condition`,
since `type_condition` will be an array of all sti subclass names for
`scope_for_create`, it is not desired behavior for `scope_for_create`,
and it will cause `find_sti_class` to fail.

That undesired behavior was derived from `In` arel node was accidentally
a subclass of `Equality` node, IMHO it is considered as almost a bug.
But someone depends on the behavior for now (see also #39288).

Unfortunately that implicit `create_with` had an unwanted side effect to
fail `or` with STI subclass relation #39956.

This changes a way to suppress/override `type_condition`, from doing
implicit `create_with` to excepting `type_condition` in `scope_for_create`,
to fix the `or` issue #39956.

On current master with multiple DBs configured, calling db:migrate:redo fails when trying to run db:rollback.

Before:

```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:rollback` you must run the namespaced task with a VERSION. Available tasks are db:rollback:primary and db:rollback:secondary.
Tasks: TOP => db:rollback
(See full trace by running task with --trace)
```

After:

```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:migrate:redo` you must run the namespaced task with a VERSION. Available tasks are db:migrate:redo:primary and db:migrate:redo:secondary.
Tasks: TOP => db:migrate:redo
(See full trace by running task with --trace)
```

Running the namespaced version:

```
» bin/rails db:migrate:redo:secondary
== 20200728162820 CreateAnimals: reverting ====================================
-- drop_table(:animals)
   -> 0.0025s
== 20200728162820 CreateAnimals: reverted (0.0047s) ===========================

== 20200728162820 CreateAnimals: migrating ====================================
-- create_table(:animals)
   -> 0.0028s
== 20200728162820 CreateAnimals: migrated (0.0029s) ===========================
```

This PR ensures that when you're generating a scaffold or model and that
model should belong to another database it will create an abstract class
if it doesn't already exist.

The new abstract class will ensure that the new model inherits from that
class, but will not be deleted if the scaffold is deleted. This is
because Rails can't know if you have other models inheriting from that
class so we don't want to revoke that if the scaffold is destroyed.

If the abstract class already exists it won't be created twice. If the
options for `parent` are set, the generator will use that as the
abstract class instead of creating one. The generated abstract class
will add the writing connection automatically, users need to add the
reading connection themselves as Rails doesn't know which is the reading
connection.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

`type_for_attribute` was added (extracted from `column_for_attribute`)
in `ModelSchema` at c93dbfef, I sometimes had expected that both
`column_for_attribute` and `type_for_attribute` exists in `ModelSchema`,
but `column_for_attribute` had existed in `AttributeMethods` even though
it's not very relevant to attribute methods (getting column object is no
longer useful for most end users since type object is separated from
column object, by the way).

So I've moved `column_for_attribute` to the same place with
`type_for_attribute` to less confusion a bit.

Similar with #39463.

Originally #39882 is intended to remove `decorate_matching_attribute_type`
but leave `decorate_attribute_type` at that point, but in the
disscussion in #39882, to demonstrate removing `AttributeDecorators`
module, I've removed all decoration methods.

I wrote user-defined type decoration as inline, I wasn't sure that is
valid (meaningful) usage (that is a reason why I wasn't in a hurry to
remove that method), as I said at https://github.com/rails/rails/pull/39882#discussion_r457750898.

In #39897 and #39902, `enum` also need to support user-defined type
decoration, so I've decided to add back `decorate_attribute_type` as
before #39882.

`attr.name` is already normalized as a string and alias resolved.

Ref #39881.

Use `arel_table` directly instead.

Avoid double time zone converter decoration when user-defined timestamp attribute with implicit type

If type is given as a symbol, it will lookup a fresh type object via
`Type.lookup`, but if type is omitted, `type_for_attribute` will lookup
the database type which is already decorated by `define_attribute`.

To avoid the double decoration, skip extra decoration if its type is
already decorated.

The internal attribute decoration is almost covered by the `attribute`
with block, we don't need to have much code and extra class attribute.

Using `decorate_matching_attribute_type` is overkill to do that.

In Active Record internal, `arel_table` is not directly used but
`arel_attribute` is used, since `arel_table` doesn't normalize an
attribute name as a string, and doesn't resolve attribute aliases.

For the above reason, `arel_attribute` should be used rather than
`arel_table`, but most people directly use `arel_table`, both
`arel_table` and `arel_attribute` are private API though.

Although I'd not recommend using private API, `arel_table` is actually
widely used, and it is also problematic for unscopeable queries and
hash-like relation merging friendly, as I explained at #39863.

To resolve the issue, this change moves Arel attribute normalization
(attribute name as a string, and attribute alias resolution) into
`arel_table`.