We should call methods with `.method_name` not `::method_name`. Fix two
instances of `YAML::load` I found in favor of `YAML.load`.

Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.

This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.

The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:

```
development:
  adapter: mysql2
  username: root
  password:

development_seconddb:
  adapter: mysql2
  username: root
  password:
  migrations_paths: "db/second_db_migrate"
```

Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".

The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.

Currently the environment is not loaded in some db tasks.
Therefore, if use encrypted secrets values in `database.yml`,
`read_encrypted_secrets` will not be true, so the value can not be
used correctly.

To fix this, added `environment` as dependency of `load_config`.
It also removes explicit `environment` dependencies that are no longer
needed.

Fixes #30717

Ensure that `bin/rails db:migrate` with specified `VERSION` reverts
all migrations only if `VERSION` is `0`.
Raise error if target migration doesn't exist.

This basically reverts 9d4f79d3

Fix `bin/rails db:setup` and `bin/rails db:test:prepare` create  wrong ar_internal_metadata's data for a test database.

  Before:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|development|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  After:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|test|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  Fixes #26731.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

Fix #28905

Add stronger assertions to rake migration tasks to make sure the user is providing a numeric VERSION
An empty string was getting converted to version = 0. This would in turn pass the presence check.

Address linting warning

Add test for rake task and refactor code to meet expectations
In particular passing VERSION=0 should not raise an error.

Addressed Comments for PR #28485. Trimmed empty lines + change of wording for error message

Adjust test for change of wording in error message

Change condition to follow rails idioms

`db:migrate` supports subdirectories and have a test.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/test/cases/migrator_test.rb#L78-L85

But `db:migrate:status` doesn't work with subdirectories. It is due to
`Dir.foreach(path)` is not the same with `Dir["#{path}/**/[0-9]*_*.rb"]`.

I extracted `migration_files` and sharing it in the both to fix the
issue. And added tests for `db:migrate:status`.

`supports_migrations?` was added at 4160b518 to determine if schema
statements (`create_table`, `drop_table`, etc) are implemented in the
adapter. But all tested databases has been supported migrations since
a4fc93c3 at least.

Today `rake db:schema:cache:dump` only supports dumping cache for a
single connection (`ActiveRecord::Base.connection`). This doesn't work
for apps with multiple databases.

This PR makes `DatabaseTasks` to provide an API for dumping schema cache
for any connection.

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

Some case expressions remain, need to think about those ones.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Rake includes (an extended version of) FileUtils in tasks.
It is more idiomatic that they use this provided interface.

- Check for protected environments while running `db:structure:load`
  similar to how `db:schema:load` behaves.
- Followup of https://github.com/rails/rails/pull/24399.

Follow up to https://github.com/rails/rails/pull/22967 to protect against
loading a schema on accident in production.

cc @schneems

This reverts a334425c.

The main reason is that now the workflow is inconsistent when using
spring.

When using spring `RAILS_ENV` is always set, so only one database is
created.

This means that in development `bin/rake db:create` and `bundle exec
rake db:create` have different results.

It also breaks the `bin/setup` script since `bin/rake db:setup
db:test:prepare` will fail.

Because of the changes in #22967 the assumption in #18907 is no longer
true because the internal metadata feature for Active Record requires
a working environment.

If for some reason some one is not able to set the environment from a migration this gives us an escape valve to manually set the environment for the database see https://github.com/rails/rails/pull/22967#issuecomment-170251635.

We will also fix the migration case, but this will ensure there is always a way to set the environment.

cc/ @sgrif

This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.

It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.

To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.

Still more to do. Please assist!

This reverts commit c2e70ca9, reversing
changes made to b0e5fc27.

this broke the build

The `rake db:test:*` tasks were deprecated in #13528, but were
undeprecated and added back in via #17739.

`1_valid_people_have_last_names.rb` and
`20150823202140_create_users.rb` are valid migration file name.
But `1_valid_people_have_last_names.rb` is rendered as
`********** NO FILE **********` when `rake db:migrate:status`.

Fix to this bug, this commit includes

* define some API private methdos and a Constant
  `match_to_migration_filename?`, `parse_migration_filename`, and
  `MigrationFilenameRegexp`
* use these methods in `db:migrate:status` task

Example:

These files are in `db/migrate`

* 1_valid_people_have_last_names.rb
* 20150819202140_irreversible_migration.rb
* 20150823202140_add_admin_flag_to_users.rb
* 20150823202141_migration_tests.rb
* 2_we_need_reminders.rb
* 3_innocent_jointable.rb

we can migrate all of them.

Before

```shell
$ bundle exec rake db:migrate:status

...

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     001             ********** NO FILE **********
   up     002             ********** NO FILE **********
   up     003             ********** NO FILE **********
   up     20150819202140  Irreversible migration
   up     20150823202140  Add admin flag to users
   up     20150823202141  Migration tests
```

After

```shell
$ bundle exec rake db:migrate:status

...

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     001             Valid people have last names
   up     002             We need reminders
   up     003             Innocent jointable
   up     20150819202140  Irreversible migration
   up     20150823202140  Add admin flag to users
   up     20150823202141  Migration tests
```

It appears that as of version 4 the `db:test:prepare` task no longer depends on the `abort_if_pending_migrations` task, which leaves this comment out of sync.

These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.

The goal is to provide the following introspection methods on the
connection:

* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)

Many user look `desc` of rake task and they are not familiar with `AR`.
`Active Record` is more familiar word.