All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.
While running Sqlite3 memory tests I encountered the following error:
```
Finished in 69.416366s, 58.0267 runs/s, 162.3681 assertions/s.
1) Error:
ActiveRecord::Migration::ChangeSchemaTest#test_add_column_with_timestamp_type:
NoMethodError: undefined method `type' for nil:NilClass
/Users/senny/Projects/rails/activerecord/test/cases/migration/change_schema_test.rb:244:in `test_add_column_with_timestamp_type'
4028 runs, 11271 assertions, 0 failures, 1 errors, 1 skips
```
This was because the table `testings` was used in multiple test-cases.
This resulted in a wrongly cached schema on `ActiveRecord::Base.schema_chae`.
/cc @zuhao
This reverts commit 5c224de9e110763ec7a0f01f5b604bcf81f40bfb.
Conflicts:
actionpack/lib/action_dispatch/journey/visitors.rb
5c224de9e110763ec7a0f01f5b604bcf81f40bfb introduced a bug in the
formatter. This commit includes a regression test.
The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.
Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.
Fix migrations that use enable_extension with table_name_prefix/suffix
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/migration.rb
The decision to wrap type registrations in a proc was made for two
reasons.
1. Some cases need to make an additional decision based on the type
(e.g. a `Decimal` with a 0 scale)
2. Aliased types are automatically updated if they type they point to is
updated later. If a user or another adapter decides to change the
object used for `decimal` columns, `numeric`, and `number` will
automatically point to the new type, without having to track what
types are aliased explicitly.
Everything else here should be pretty straightforward. PostgreSQL ranges
had to change slightly, since the `simplified_type` method is gone.
