Rails changes schema.rb timestamps to datetimes
activerecord, postgresql, rails-migrations, ruby-on-rails
Solution
This should not be causing any 'reindexation', because the `:datetime` and `:timestamp` migration types are both mapped to PostgreSQL's `TIMESTAMP` datatype.
This is likely caused as a result of the inherently unordered `ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES` constant which is defined as a standard hash. When ActiveRecord searches for the first suitable match for 'TIMESTAMP', it may find either `:datetime` or `:timestamp` unpredictably (since both are matches).
In short, don't fuss about it as this shouldn't affect your data or schema in the least.
UPDATE
The rails 'datatype' used in the dump is found using the `simplified_type` method which will return `:datetime` for the TIMESTAMP datatype. More likely, you have upgraded your Rails version where the previous version had a different method for determining the datatype. Whatever the reason, this shouldn't affect you in any way.
Problem
This problem seems to happen all the time when working with other developers. We have a table created in a migration like so (backed by postgres): ``` create_table :subscription_events do |t| t.integer :subscriber_id t.text :source_url t.text :params t.text :session t.timestamps end ``` Then at seemingly random points in time in the future after running rake db:migrate, Rails wants to update the schema.rb file to use `datetime` instead of `timestamp`, causing an additionally confusing reindentation of the whole create_table calls as well: ``` create_table "subscription_events", :force => true do |t| - t.integer "subscriber_id" - t.text "source_url" - t.text "params" - t.text "session" - t.timestamp "created_at", :limit => 6, :null => false - t.timestamp "updated_at", :limit => 6, :null => false + t.integer "subscriber_id" + t.text "source_url" + t.text "params" + t.text "session" + t.datetime "created_at", :null => false + t.datetime "updated_at", :null => false end ``` What is causing this? Should we be checking in this modified file or just reset it every time?