Actually, `first` taking non-deterministic result is considered a bug to
me. But changing the behavior should not be happened in rc2.

I've restored the behavior for 6.0, and then will deprecate that in 6.1.

Fixes #36802.

Make sure primary keys with non-integer types can be correctly type
casted in through reflections.

c9e4c848 has one performance optimization for `aggregate_alias` to early
returning by `aggregate_alias.match?(/\A\w+\z/)`, but it is caused a
regression that failing deduplication for non word chars #36867.

I've quited the optimization and add a test to prevent a future
regression.

Fixes #36867.

As demonstrated in the test added and in #36830 the code that prevents
writes wasn't thread safe. If one thread does a read, then another does
a write, and then another does a read the second read will cause the
first write to be unwriteable.

This change removes the instance variable and instead uses a
getter/setter on Thread.current[:prevent_writes] for the connection
handler to set whether writes are allowed.

Fixes #36830

```ruby
$ cd activerecord
$ bin/test test/cases/dirty_test.rb:494
... snip ...
DEPRECATED: Use assert_nil if expecting nil from /home/yahonda/git/rails/activerecord/test/cases/dirty_test.rb:494. This will fail in Minitest 6.
DEPRECATED: Use assert_nil if expecting nil from /home/yahonda/git/rails/activerecord/test/cases/dirty_test.rb:511. This will fail in Minitest 6.
.

Finished in 0.061593s, 16.2356 runs/s, 795.5428 assertions/s.
1 runs, 49 assertions, 0 failures, 0 errors, 0 skips
$
```

Refer seattlerb/minitest#666 rails/rails#27712

Previously if an app attempts to do a write inside a read request it will be
impossilbe to switch back to writing to the primary. This PR adds an
argument to the `while_preventing_writes` so that we can make sure to
turn it off if we're doing a write on a primary.

Fixes #36830
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

This reverts commit 98d0f7eb.

It's used everywhere, clean and mature enough

In our app at work we had a faked config like this:

```
{ "foo" => :bar, "bar" => { "adapter" => "memory" } }
```

This config is invalid. You can't say for foo env just have a symbol,
nor would this work if you had fa foo env with just a string. A
configuration must be a url or an adapter or a database. Otherwise it's
invalid and we can't parse it.

When this was just yaml turned into hashes you could get away with
passing whatever. It wouldn't work but it wouldn't blow up either.

Now that we're using objects we were returning `nil` for these but that
just means we either blow up on `for_current_env` or compact the
`nil`'s.

I think it's a better user experience to not build the configs and raise
an appropriate error.

This is also an invalid config because if you do pass a string here it
should be a URL.

```
{ "foo" => "bar", "bar" => { "adapter" => "memory" } }
```

#36805 have one possible regression that failing deduplication if
`joins_values` have complex order (e.g. `joins_values = [join_node_a,
:comments, :tags, join_node_a]`).

This fixes the deduplication to take it in the first phase before
grouping.

These tests verifies that aggregates like `AVG` can be selected as
"virtual attributes" on Active Record models and have the correct
column type.

In case of a polymorphic association there's no automatic inverse_of to assign the
inverse record. So to get the record there needs to be a query executed,
however, if the query fires within the transaction that's trying to create
the associated record, no record can be found. And worse, the nil result is cached
on the association so after the transaction commits the record can't be found.

That's what happens if touch is enabled on a polymorphic has_one association.

Consider a Comment with a commentable association that needs to be touched.

For `Comment.create(commentable: Post.new)`, the existing code essentially
does `commentable.send(:comment)` within the create transaction for the comment
and thus not finding the comment.

Now we're purposefully clearing the cache in case we've tried accessing
the association within the transaction and found no object.

Before:

```
kaspth-imac 2.6.3 ~/code/rails/activerecord master *= ARCONN=postgresql bin/test test/cases/associations/has_one_associations_test.rb -n /commit/
Using postgresql
Run options: -n /commit/ --seed 46022

D, [2019-07-19T03:30:37.864537 #96022] DEBUG -- :   Chef Load (0.2ms)  SELECT "chefs".* FROM "chefs" WHERE "chefs"."employable_id" = $1 AND "chefs"."employable_type" = $2 LIMIT $3  [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"], ["LIMIT", 1]]
D, [2019-07-19T03:30:37.865013 #96022] DEBUG -- :   Chef Create (0.2ms)  INSERT INTO "chefs" ("employable_id", "employable_type") VALUES ($1, $2) RETURNING "id"  [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"]]
D, [2019-07-19T03:30:37.865201 #96022] DEBUG -- :   TRANSACTION (0.1ms)  RELEASE SAVEPOINT active_record_1
D, [2019-07-19T03:30:37.874136 #96022] DEBUG -- :   TRANSACTION (0.1ms)  ROLLBACK
D, [2019-07-19T03:30:37.874323 #96022] DEBUG -- :   TRANSACTION (0.1ms)  ROLLBACK
F

Failure:
HasOneAssociationsTest#test_polymorphic_has_one_with_touch_option_on_create_wont_cache_assocation_so_fetching_after_transaction_commit_works [/Users/kaspth/code/rails/activerecord/test/cases/associations/has_one_associations_test.rb:716]:
--- expected
+++ actual
@@ -1 +1 @@
-#<Chef id: 1, employable_id: 1, employable_type: "DrinkDesignerWithPolymorphicTouchChef", department_id: nil, employable_list_type: nil, employable_list_id: nil>
+nil
```

After:

```
kaspth-imac 2.6.3 ~/code/rails/activerecord master *= ARCONN=postgresql bin/test test/cases/associations/has_one_associations_test.rb -n /commit/
Using postgresql
Run options: -n /commit/ --seed 46022

D, [2019-07-19T03:30:22.479387 #95973] DEBUG -- :   Chef Create (0.3ms)  INSERT INTO "chefs" ("employable_id", "employable_type") VALUES ($1, $2) RETURNING "id"  [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"]]
D, [2019-07-19T03:30:22.479574 #95973] DEBUG -- :   TRANSACTION (0.1ms)  RELEASE SAVEPOINT active_record_1
D, [2019-07-19T03:30:22.482051 #95973] DEBUG -- :   Chef Load (0.1ms)  SELECT "chefs".* FROM "chefs" WHERE "chefs"."employable_id" = $1 AND "chefs"."employable_type" = $2 LIMIT $3  [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"], ["LIMIT", 1]]
D, [2019-07-19T03:30:22.482317 #95973] DEBUG -- :   TRANSACTION (0.1ms)  ROLLBACK
D, [2019-07-19T03:30:22.482437 #95973] DEBUG -- :   TRANSACTION (0.1ms)  ROLLBACK
.

Finished in 0.088498s, 11.2997 runs/s, 22.5994 assertions/s.
1 runs, 2 assertions, 0 failures, 0 errors, 0 skips
```

Notice the select now fires after the commit.

To suppress the following warnings in tests.

```
~/rails/activerecord/lib/active_record/scoping/named.rb:190: warning: method redefined; discarding old not_sent
~/rails/activerecord/lib/active_record/scoping/named.rb:190: warning: previous definition of not_sent was here
```

Currently, string joins are always applied as last joins part, and Arel
join nodes are always applied as leading joins part (since #36304), it
makes people struggled to preserve user supplied joins order.

To mitigate this problem, preserve the order of string joins and Arel
join nodes either before or after of association joins.

Fixes #36761.
Fixes #34328.
Fixes #24281.
Fixes #12953.

Previously it was the responsibility of the database tasks to translate
the invalid statement from creating a duplicate database into an
ActiveRecord::Tasks::DatabaseAlreadyExists error.

It's actually easier for us to do this detection inside of the adapter,
where we already do a case statement on the return code to translate the
error.

This commit introduces ActiveRecord::DatabaseAlreadyExists, a subclass
of StatementInvalid, and updates both AbstractMysqlAdapter and
PostgresqlAdapter to return this more specific exception in that case.

Because this is a subclass of the old exception, StatementInvalid, it
should be backwards compatible with any code expecting that from
create_database.

This works for both create_database and exectute("CREATE DATABASE")

Previously matches_regex was only availble on PostgreSql, this will enable it for MySql

Usage example:

    users = User.arel_table;
    users = User.arel_table; User.where(users[:email].matches_regexp('(.*)\@gmail.com'))

Update activerecord/test/cases/arel/visitors/mysql_test.rb
Co-Authored-By: NRyuta Kamizono <kamipo@gmail.com>

Allow specifying what fixtures can be ignored by setting
`ignore` in fixtures YAML file:

    # users.yml
    _fixture:
      ignore:
        - base

    base: &base
      admin: false
      introduction: "This is a default description"

    admin:
      <<: *base
      admin: true

    visitor:
      <<: *base

In the above example, "base" fixture will be ignored when creating
users fixture. This is helpful when you want to inherit attributes
and it makes your fixtures more "DRY".

To avoid a deprecation warning.

We're already running Performance/RegexpMatch cop, but it seems like the cop is not always =~ justice

This commit adds a feature which allows separate database ENV variables
to be defined for each spec in a 3-tier config. The names for the
environment variables will be `#{name.upcase}_DATABASE_URL`

This commit also introduces a change in behavior around handling of
`DATABASE_URL`. Instead of using `DATABASE_URL` to change _all_ specs
in a multi-database configuration, it will now only affect the `primary`
connection.

Don't break configurations.each, .first before the deprecation period

In using HABTM, join middle table alias is combined with the associated
models name without sort, while middle table name is combined with those
models name with sort.

Fixes #36742.

This commit fixes a regression where when the `DATABASE_URL` environment
variable was set and the current Rails environment had a valid configuration
defined in the database config, settings from the environment variable would
affect _all_ environments (not just the current one).

MySQLDatabaseTasks, like AbstractMysqlAdapter, should be able to operate
on any mysql adapter, not just mysql2. Errors having a .error_number
attribute is a mysql2 specific API, which we (Rails) don't control, so
we should instead use connection.error_number(err), which we do.

This also updates tests to better test how this really works, previously
it stubbed create_database to raise Tasks::DatabaseAlreadyExists, which
can never happen.

Previously Rails expected indexes to be an array of columns, but for
PostgreSQL a expression index can just be a string of text. Handle this
by forcing `Index#columns` to be an Array inside `index_exists?`.

Closes #36739

This commit fixes an issue where multi-database configurations were
incompatible with setting a `DATABASE_URL` environment variable.

As part of this work, this commit also includes a light refactor
to make both multi and single database configurations lead into the same
code path so they behave the same.

As mentioned in #36736, this regression was introduced as part of
f2ad69fe

Ruby 2.7 introduces beginless ranges (..value and ...value) and as with
endless ranges we can turn these into inequalities, enabling expressions
such as

    Order.where(created_at: ..1.year.ago)
    User.where(karma: ...0)

- One regression introduced by the "AM errors as object" features is
  about the `full_messages` method.

  It's currently impossible to call that method if the `base` object
  passed in the constructor of `AM::Errors` doesn't respond to the
  `errors` method.
  That's because `full_messages` now makes a weird back and forth trip

  `AM::Errors#full_messages` -> `AM::Error#full_message` -> `AM::Errors#full_message`

  Since `full_message` (singular) isn't needed by AM::Errors, I moved
  it to the `AM::Error` (singular) class. This way we don't need to
  grab the `AM::Errors` object from the base.

Fixes #36581.

This fixes an issue where validations would return differently when a previously saved invalid association was loaded between calls:

    assert_equal true, squeak.valid?
    assert_equal true, squeak.mouse.present?
    assert_equal true, squeak.valid?

Here the second assert would return

    Expected: true
    Actual: false

Limiting validations to associations that would be normally saved (using autosave: true) due to changes means that loading invalid associated relations will not change the return value of the parent relations's `valid?` method.