In 154abcab we switched from using `Rails.env` to fetch the `env_name` to
`ActiveRecord::ConnectionHandling::DEFAULT_ENV.call.to_sym` which
changed the type from a `String` to a `Symbol`.

This commit brings things back to the original state, so we can find the
configurations correctly!

It also modifies the configuration in the configurations array, so that
future connections can find the database with the updated keyword value.

Add ActiveRecord::Relation#cache_key_with_version. This method will be
used by ActionController::ConditionalGet to ensure that when collection
cache versioning is enabled, requests using ConditionalGet don't return
the same ETag header after a collection is modified.

Prior to the introduction of collection cache versioning in
4f2ac80d, all collection cache keys
included a version. However, with cache versioning enabled, collection
cache keys remain constant. In turn, ETag headers remain constant,
rendering them ineffective.

This commit takes the cache_key_with_version method used for individual
Active Record objects (from aa8749eb),
and adds it to collections.

In arel, there is a space between the table name and columns list when INSERT.
https://github.com/rails/rails/blob/3c28e79b615f6937f5abdc433ff634d15cf2466f/activerecord/lib/arel/visitors/to_sql.rb#L56

```ruby
User.create!(name: "foo")
# INSERT INTO `users` (`name`) VALUES ('foo')
              ^^^^^^^^^^^^^^^^
```

But SQL of insert_all is not separated.

```ruby
User.insert_all!([{name: "foo"}])
# INSERT INTO `users`(`name`) VALUES ('foo')
              ^^^^^^^^^^^^^^^
```

This is not a problem (because it is correct as SQL), but fixing this will make unified behavior.

A known issue is that database_rewinder fails to parse table name on insert_all.
https://github.com/amatsuda/database_rewinder/blob/v0.9.1/lib/database_rewinder.rb#L51-L54

```ruby
statement = "INSERT INTO `users`(`name`) VALUES ('foo')"
match = statement.match(/\A\s*INSERT(?:\s+IGNORE)?(?:\s+INTO)?\s+(?:\.*[`"]?([^.\s`"]+)[`"]?)*/i)
# => #<MatchData "INSERT INTO `users`(`name`)" 1:")">
# Expected behavior is
# => #<MatchData "INSERT INTO `users`" 1:"users">
```

The `_trigger_update_callback` and `_trigger_destroy_callback`
attributes were added in 9252da96 to
avoid running transactional callbacks when an attempt to modify a record
fails inside a transaction due to the record being invalid, for example.

However the values weren't being reset between transactions, which meant
they leaked from one transaction to another and caused false positives
where unsuccessful modifications still triggered callbacks. Clearing
them when a transaction commits or is rolled back fixes the problem.

If `AR::Enum` is used for boolean field, it would be not expected
behavior for us.

fixes #38075

Problem:

In case of using boolean for enum, we can set with string (hash key)
to instance, but we cannot set with actual value (hash value).

```ruby
class Post < ActiveRecord::Base
  enum status: { enabled: true, disabled: false }
end

post.status = 'enabled'
post.status # 'enabled'

post.status = true
post.status # 'enabled'

post.status = 'disabled'
post.status # 'disabled'

post.status = false
post.status # nil (This is not expected behavior)
```

After looking into `AR::Enum::EnumType#cast`, I found that `blank?`
method converts from false value to nil (it seems it may not intentional behavior).

In this patch, I improved that if it defines enum with boolean,
it returns reasonable behavior.

The regular expression did not match CREATE TABLE statements printed out by AWS Aurora MySQL 5.6 instances, because they lack the required space at that position.

Fixes https://github.com/rails/rails/issues/28827.

The steps to reproduce are as follows:

git clone git@github.com:bbuchalter/rails-issue-28827.git
cd rails-issue-28827
bundle install
bin/rails db:create

Observe that we create two databases when invoking db:create: development and test. Now observe what happens when we invoke our drop command while using DATABASE_URL.

DATABASE_URL=sqlite3://$(pwd)/db/database_url.sqlite3 bin/rails db:create

As expected, the development environment now uses the DATABASE_URL. What is unexpected is that the test environment does not.

It's unclear what the expected behavior should be in this case, but the cause of it is this: https://github.com/rails/rails/blob/9f2c74eda07ea5a9e4e624d5575a717714088dbf/activerecord/lib/active_record/tasks/database_tasks.rb#L494

Because of each_local_configuration, there seems to be no way invoke these database rake on only the development environment to ensure DATABASE_URL is respected.

The smallest scope of change I can think to make would be to conditionalize this behavior so it does not get applied when DATABASE_URL is present.

Activerecord ruby 2.7 warnings 6 0 stable batch 2

This adds `:declare`, `:fetch`, `:move`, and `:close` to allowed queries
when `while_preventing_writes` is set. I didn't support `:open` because
AFAICT `:declar` implcitly opens a cursor and all of my attempts to
write `@connection.execute("OPEN cur_ex")` threw a syntax error on
`OPEN`. It seems like open isn't supported with the client.

Fixes: #37960

`:begin, :commit, :explain, :release, :rollback, :savepoint, :select,
:with` are used by all the adapters. This commit adds a new constant
called `DEFAULT_READ_QUERY` so that we have somewhere to put the
queries used by all the adapters. Then we can set adapter specific query
parts in those adapters.

I also alphabetized these.

We want to introduce an object-based DSL for building and modifying
configuration objects. As part of that we want to make sure that users
don't think they can modify configuration_hash values and have them
change the configuration. For that reason we're going to freeze the
Hash here, and have modified places in tests where we were modifying
these hashes.

The commit here also adds a test for the Test Databases and in that work
we found that we were calling `Rails.env` and Active Record doesn't load
Rails.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

Related #36456.

I grepped the code base by `git grep -n 'connection_id: '` then I found
extra `connection_id: object_id` which is added at #20818 but unused.

Actually the `connection_id: object_id` is not a connection's object_id
but a connection_handler's object_id, it is very confusing.

Since the `:connection_id` in an internal instrument is not used, we can
just remove the incorrect information.

`name` is used by Rails to find the configuration by connection
specification name, but database adapters don't need to use `name` in
order to establish a connection. This is part of our work to separate
what the database needs to connect (the configuration hash) and the
what Rails needs to find connections (everything else).
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

- I'm hoping to get this change accepted even though this flag was
  introduced years ago in 6576f735

  My use case is the following:

  We were never enforcing belongs to association and we have a lot
  of models that implicitely declare an association as optional.
  We are now changing all our models to make associations required
  by default.
  Since we have a lot of models (more than 1000), I'd like to
  progressively enable them to use the `belongs_to_required_by_default`
  flag.

  The problem is that this flag is a mattr_accessor and doesn't to be
  set per model. We basically need to modify all our models (which
  could take years) before being able to modify the global flag.

  I'd like to change this flag to a class_attribute to solve the
  issue.

The `connection_config` method returns a `Hash`, but since we're moving
toward a place where we're using `DatabaseConfiguration::DatabaseConfig`
objects everywhere, we're introducing a new method here to replace it
called `connection_db_config`.
Co-authored-by: Neileencodes <eileencodes@gmail.com>

This is the last property that's used directly inside of Rails (in
`DatabaseTasks`) that doesn't have an accessor in `HashConfig`.

Adding this so that we can have a uniform interface for accessing
properties that Rails needs (that descend from
`DatabaseConfigurations::DatabaseConfig`)
Co-authored-by: Neileencodes <eileencodes@gmail.com>

When rails is configured to use a specific primary key type:
```
config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end
```

Previously:

    $ bin/rails g migration add_location_to_users location:references

The references line in the migration would not have `type: :uuid`.
This change causes the type to be applied appropriately.
Co-authored-by: NDermot Haughey <hderms@gmail.com>

- #37798 had to be reverted because a new flakyness appeared ([see
  CI build](https://buildkite.com/rails/rails/builds/65467#efaa1dd5-aaf4-43a1-a204-d1c42abf614d))

  This failure isn't related to the change itself.
  If you apply this diff, the test will some time to time fail.
  Even without my changes.

  ```diff
  diff --git a/activerecord/test/cases/transactions_test.rb b/activerecord/test/cases/transactions_test.rb
index b5c1cac3d9..09fe0ddd7f 100644
--- a/activerecord/test/cases/transactions_test.rb
+++ b/activerecord/test/cases/transactions_test.rb
@@ -1127,7 +1127,6 @@ def test_no_automatic_savepoint_for_inner_transaction
   end
 end if Topic.connection.supports_savepoints?

-if ActiveRecord::Base.connection.supports_transaction_isolation?
   class ConcurrentTransactionTest < TransactionTest
     # This will cause transactions to overlap and fail unless they are performed on
     # separate database connections.
@@ -1198,4 +1197,3 @@ def test_transaction_isolation__read_committed
       assert_equal original_salary, Developer.find(1).salary
     end
   end
-end
  ```

  SQlite3 isn't safe to run in a multi threaded environment unless
  sqlite is compiled with a special flag which isn't our case.
  Ref https://www.sqlite.org/threadsafe.html

This constant is no longer useful since 58df9a45.

This reverts commit 25daafbc.

`DEFAULT_VALUES` access is a bit slower, avoiding that makes about 45%
faster query methods.

https://gist.github.com/kamipo/e64439f7a206e1c5b5c69d92d982828e

Before (ff299f17):

```
Warming up --------------------------------------
        #limit_value   263.800k i/100ms
    #limit_value = 1   241.758k i/100ms
Calculating -------------------------------------
        #limit_value      7.044M (± 1.5%) i/s -     35.349M in   5.019511s
    #limit_value = 1      6.044M (± 2.3%) i/s -     30.220M in   5.003292s
```

After (this change):

```
Warming up --------------------------------------
        #limit_value   246.295k i/100ms
    #limit_value = 1   244.398k i/100ms
Calculating -------------------------------------
        #limit_value     10.303M (± 2.1%) i/s -     51.722M in   5.022568s
    #limit_value = 1      6.021M (± 6.1%) i/s -     30.061M in   5.015545s
```

We should set the `@records` and `@loaded` ivar inside `#load` rather
than in `#exec_queries`. Since `#load` is running `#exec_queries` and
`@records` can only be assigned if `loaded?` is true and `@loaded` can
only be set if `loaded?` is true then `#load` should do the assignment.
This is cleaner but also we came across this while working on an
internal gem and realized that the ivar assignment was happening in the
wrong place.
Co-authored-by: NAaron Patterson <aaron.patterson@gmail.com>

This reverts commit b4ab1f19, reversing
changes made to 9926fd86.

This is causing CI to fail about 50% of the time, and can be reproduced
locally 100% of the time on my machine.

Ex failing build https://buildkite.com/rails/rails/builds/65467#efaa1dd5-aaf4-43a1-a204-d1c42abf614d

Error:

```
SQLite3::BusyException: database is locked (ActiveRecord::StatementInvalid)
```

A querystring value should be allowed to include an equal sign `=`.

This is necessary to support passing `options` for a PostgresSQL connection.

```

development:
  url: postgresql://localhost/railsdevapp_development?options=-cmysetting.debug=on
```

Before this PR, attempting to start the rails process with that configuration would result in an error:

```
> bundle exec rails console
Traceback (most recent call last):
	49: from bin/rails:4:in `<main>'
	48: from bin/rails:4:in `require'
...
	 1: from /rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `query_hash'
/rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `[]': invalid number of elements (3 for 1..2) (ArgumentError)
```

After this PR, rails can properly parse the configuration:

```
> bundle exec rails console
Loading development environment (Rails 6.1.0.alpha)
2.6.5 :001 > ActiveRecord::Base.connection.select_all("show mysetting.debug").to_a
   (0.4ms)  show mysetting.debug
 => [{"mysetting.debug"=>"on"}]
```

- SQlite allow database to be specified as URL (given that URI filename
  interpretation was turned on on the connection.)

  This commit is necessary for the read_uncommitted transaction
  feature because SQLite doesn't allow to enable the shared-cache mode
  if the database name is `:memory:`. It has to be a URI (`file::memory`)

  Ref https://www.sqlite.org/sharedcache.html#shared_cache_and_in_memory_databases

- ### Use case

  I'd like to be able to see changes made by a connection writer
  within a connection reader before the writer transaction commits
  (aka `read_uncommitted` transaction isolation level).

  ```ruby
  conn1.transaction do
    Dog.create(name: 'Fido')
    conn2.transaction do
      Dog.find(name: 'Fido') # -> Can't see the dog untill conn1 commits the transaction
    end
  end
  ```

  Other adapters in Rails (mysql, postgres) already supports multiple
  types of isolated db transaction.
  SQLite doesn't support the 4 main ones but it supports
  `read_uncommitted` and `serializable` (the default one when opening
  a transaction)

  ### Solution

  This PR allow developers to open a `read_uncommitted` transaction by
  setting the PRAGMA `read_uncommitted` to true for the duration
  of the transaction. That PRAGMA can only be enabled if the SQLite
  connection was established with the [shared-cache mode](https://www.sqlite.org/sharedcache.html)

  This feature can also benefit the framework and we could potentially
  get rid of the `setup_shared_connection_pool` inside tests which
  was a solution in the context of a multi-db app so that the reader
  can see stuff from the open transaction writer but has some [caveats](https://github.com/rails/rails/issues/37765#event-2828609021).

  ### Edge case

  Shared-cache mode can be enabled for in memory database as well,
  however for backward compatibility reasons, SQLite only allows
  to set the shared-cache mode if the database name is a URI.
  It won't allow it if the database name is `:memory`; it has to be
  changed to `file::memory` instead.

This reverts commit 4e105385, reversing
changes made to 62b43839.

The change in Ruby that made those changes required was reverted in
https://bugs.ruby-lang.org/projects/ruby-trunk/repository/git/revisions/8852fa876039ed177fd5e867f36177d8a9ff411c

Applying `includes` and `joins` to a relation that selected additional
database fields would cause those additional fields not to be included
in the results even though they were queried from the database:

    posts = Post.select('1 as other').includes(:tbl).joins(:tbl)

    posts.to_sql.include?('1 as other')       #=> true
    posts.first.attributes.include?('other')  #=> false

This commit includes these additionally selected fields in the
instantiated results.

The `database` kwarg in `connected_to` has resulted in a lot of bug
reports that are trying to use it for sharding when that's not the
intent of the key. After considering where the database kwarg is used in
tests and thinking about usecases for it, we've determined it should be
removed.

There are plans to add sharding support and in the mean time the
database kwarg isn't the right solution for that. Applications that need
to create new connections can use establish_connection or connects_to.
Since the database key causes new connections to be established on every
call, that causes bugs if connected_to with a database kwarg is used
during a request or for any connection that's not a one-off.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

If a spec name was provided without an env name, config_for would return
the first config that matched the spec, regardless of environment name.

Now configs_for will return the database config that matches the
default env and requested spec name.

Additionally this commit has moved the default env call into a method
because I'm tired of typing so many lines every single time.

We considered either returning all configs that match that spec name or
raising an error if only spec was passed, but this change has the least
impact on current behavior and matches Active Record's assumptions: that
if you ask for configs it will always consider the current environment.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

https://github.com/rubocop-hq/rubocop/releases/tag/v0.77.0

* Update cop names to changed as follows:

```
$ bundle exec rubocop
Error: The `Layout/IndentFirstArgument` cop has been renamed to `Layout/FirstArgumentIndentation`.
(obsolete configuration found in .rubocop.yml, please update it)
The `Layout/TrailingBlankLines` cop has been renamed to `Layout/TrailingEmptyLines`.
(obsolete configuration found in .rubocop.yml, please update it)
The `Lint/StringConversionInInterpolation` cop has been renamed to `Lint/RedundantStringCoercion`.
(obsolete configuration found in .rubocop.yml, please update it)
$
```

* Auto correct these offenses:

```
$ bundle exec rubocop -a
... snip ...
Offenses:

activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb:104:11: C: [Corrected] Style/RedundantReturn: Redundant return detected.
          return true
          ^^^^^^
activerecord/lib/active_record/reflection.rb:622:15: C: [Corrected] Style/RedundantReturn: Redundant return detected.
              return inverse_name
              ^^^^^^
activerecord/lib/active_record/table_metadata.rb:48:9: C: [Corrected] Style/RedundantReturn: Redundant return detected.
        return self
        ^^^^^^

2812 files inspected, 3 offenses detected, 3 offenses corrected
$
```

The text of error messages from a PostgreSQL server depend on the
setting "lc_messages" in postgresql.conf.
The current detection of the particular error condition of an invalid
plan therefore works with English language setting on the server only.
Other locale settings result in a wrong exception type, which lead
to two test failures:

HotCompatibilityTest#test_cleans_up_after_prepared_statement_failure_in_a_transaction [test/cases/hot_compatibility_test.rb:75]:
[ActiveRecord::PreparedStatementCacheExpired] exception expected, not
Class: <ActiveRecord::StatementInvalid>
Message: <"PG::FeatureNotSupported: FEHLER:  gecachter Plan darf den Ergebnistyp nicht ändern\n">

Here the German message wasn't recognized, so that an StatementInvalid
is raised instead of PreparedStatementCacheExpired.

Using the PG_DIAG_SOURCE_FUNCTION is independent of the locale setting.
It is not guarantied to be stable, but it has been unchanged since PostgreSQL-9.2.
On the other hand the text to be matched isn't guarantied to be stable either.