Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.

And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.

Such as #10404, #18206.

Example:

    create_table :barcodes, primary_key: ["region", "code"] do |t|
      t.string :region
      t.integer :code
    end

Example:

    create_table :foos do |t|
      t.integer :unsigned_integer, unsigned: true
      t.bigint  :unsigned_bigint,  unsigned: true
      t.float   :unsigned_float,   unsigned: true
      t.decimal :unsigned_decimal, unsigned: true, precision: 10, scale: 2
    end

 - Followup of https://github.com/rails/rails/pull/20190/.

    `widgets` table is being created in `primary_keys_test.rb` for PostgreSQLAdapter, MysqlAdapter, Mysql2Adapter
    and it makes test to fail earlier.

    Before:
      `bundle exec rake mysql2:test`

    ```
    Finished in 127.287669s, 35.5258 runs/s, 97.8885 assertions/s.

      1) Error:
    PersistenceTest::SaveTest#test_save_touch_false:
    ActiveModel::UnknownAttributeError: unknown attribute 'name' for #<Class:0x0000000a7d6ef0>.
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:36:in `rescue in _assign_attribute'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:34:in `_assign_attribute'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `each'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/core.rb:293:in `initialize'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/persistence.rb:50:in `create!'
        /home/kd/projects/kd-rails/activerecord/test/cases/persistence_test.rb:913:in `test_save_touch_false'

    4522 runs, 12460 assertions, 0 failures, 1 errors, 4 skips
    ```

    After:
      `bundle exec rake mysql2:test`

    ```
       Finished in 135.785086s, 33.3026 runs/s, 91.7774 assertions/s.

       4522 runs, 12462 assertions, 0 failures, 0 errors, 4 skips
    ```

I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.

I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.

I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.

Example:

    create_table :foos, id: :primary_key, limit: 8 do |t|
    end

    # or

    create_table :foos, id: false do |t|
      t.column :id, limit: 8
    end

Lowercase raw SQL has been replaced by 07b659ca already. This commit
replaces everything else of raw SQL.

since 'drop table if exists' statement does not always work with some databases such as Oracle.
also Oracle drop table statement will not drop sequence objects.

If it is not a default primary key, correctly dump the type and options.

Example:

    create_table :foos, id: :bigint do |t|
    end

Currently when we call id_was and we have a custom primary key name
Active Record will return the current value of the primary key. This
make impossible to correctly do an update operation if you change the
id.

Fixes #16413

Making this change revealed several subtle bugs related to models with
no primary key, and anonymous classes. These have been fixed as well,
with regression tests added.

/cc @zuhao

It appears to have been used at some point in the past, but is no longer
used in any meaningful way. Whether a column is considered primary is
a property of the model, not the schema/column. This also removes the
need for yet another layer of caching of the model's schema, and we can
leave that to the schema cache.

In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.

Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.

This behavior was introduced since Rails 3.1 (207f266c)
but the docs were still out of date.

We can conditional define the tests depending on the adapter or
connection.

Lets keep the skip for fail tests that need to be fixed.

This reverts commit 3043d45e, reversing
changes made to ca0275d3.

In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.

Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.

This reverts commit 637a7d9d, reversing
changes made to 5937bd02.

This reverts commit 90c887fa.

In the end I think the pain of implementing this seamlessly was not
worth the gain provided.

The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.

Allows two models to use the same table but have different primary keys.

Also make it actually work.

It slows down all read_attribute accesses to map 'id' to whatever the PK
actually is, inside read_attribute. So instead make sure the necessary
methods are defined and that they redirect wherever they need to go.

You can use multiple databases in your tests without disabling transactional fixtures.