`ColumnDumper#migration_keys` was extracted to customize keys for
standardized column arguments widths. But the feature was removed in
df84e986. The internal method is no longer used for that.

These internal initialize methods are no longer used internally.

This reverts commit 39c77eb1, reversing
changes made to 9f6f51be.

Remove `initialize_schema_migrations_table` and `initialize_internal_metadata_table` internal public methods

These internal methods accidentally appeared in the doc, and so almost
useless. It is enough to create these internal tables directly, and
indeed do so in several places.

https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/schema.rb#L55
https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/railties/databases.rake#L6
https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/tasks/database_tasks.rb#L230

- Reference: https://travis-ci.org/rails/rails/jobs/189764676

- Reproduction command:

    MTB_VERBOSE=2 bundle exec minitest_bisect --seed 33328 -Itest "test/cases/migration_test.rb" "test/cases/tasks/database_tasks_test.rb"

- You need to also add minitest_bisect gem to the Gemfile to reproduce
  this failure.

invalid column type
    /activerecord/lib/active_record/connection_adapters
    /abstract/schema_definitions.rb:306
    type = type.to_sym

Changed to the following to handle nil case:
    type = type.to_sym if type

Added regression test for this case:
  /activerecord/test/cases/migration_test.rb:554
  if current_adapter?(:SQLite3Adapter)
    def test_allows_sqlite3_rollback_on_invalid_column_type
      Person.connection.create_table :something, force: true do |t|
        t.column :number, :integer
        t.column :name, :string
        t.column :foo, :bar
      end
      assert Person.connection.column_exists?(:something, :foo)
      assert_nothing_raised { Person.connection.remove_column :something, :foo, :bar }
      assert !Person.connection.column_exists?(:something, :foo)
      assert Person.connection.column_exists?(:something, :name)
      assert Person.connection.column_exists?(:something, :number)
    ensure
      Person.connection.drop_table :something, if_exists: true
    end
  end

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

A few have been left for aesthetic reasons, but have made a pass
and removed most of them.

Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.

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

This reverts commit 407e0ab5.

Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005

* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.

Rails should not be explicity mentioned within Active Record, since
railties and the Rails ecosystem is not required for use.

`#first_or_initialize` does not use attributes to data acquisition.
Therefore, there is a possibility of updating the different record than the one
specified in the key, I think this is not expected behavior.

The error is raised because user passed invalid version number to a public api of
`ActiveRecord`, so `ArgumentError` is more suitable.
And add a test case checking if an error is raised when unknown migration version
is passed, because these test cases are not implemented.

I was encountered remaining `:binary_testings` table by tests failure.
When remaining `:binary_testings` table, never reach `drop_table` due to
`create_table` in the test always fails.

Follow up to 3b017856.

We are creating the table but not deleting after the test.

A `:test_limits` table has not been created.

Follow up of https://github.com/rails/rails/commit/c9feea6c9ab4494b0cb0b8cf4316847854f65af6

for those who already migrated to Rails 5.0.0 beta

to support Oracle database which only supports 30 byte identifier length

😳

This reverts commit 11e85b91.

This PR addresses the issue described in https://github.com/rails/rails/pull/22967#issuecomment-170251635. If the database is non empty and has no new migrations than `db:migrate` will not set the environment. This PR works by always setting the environment value on successful `up` migration regardless of whether or not a migration was actually executed.

Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035

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`.

This test was failing when run on Windows using PostgreSQL. Depending on
the OS (and 32 vs 64 bit), this type could be a `BigNum`. We could loosen
the assertion to `Numeric`, but if the value is equal to the expected, and
responds to `bitlength` properly, who cares?

Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.

Application code should *not* do this.

This reverts commit 8246b593.

There was concern about this modifying the behavior of past migrations.
We're going to add an way to modify the migration generator instead.