在与其他开发人员合作时,这个问题似乎一直都在发生。我们在这样的迁移中创建了一个表(由 postgres 支持):
create_table :subscription_events do |t|
t.integer :subscriber_id
t.text :source_url
t.text :params
t.text :session
t.timestamps
end
然后在运行 rake db:migrate 之后看似随机的时间点,Rails 想要更新 schema.rb 文件以使用 datetime
而不是 timestamp
,还导致整个 create_table 调用的重新缩进更加困惑:
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
这是什么原因造成的?我们应该 checkin 这个修改后的文件还是每次都重置它?
最佳答案
这不应该导致任何“重建索引”,因为 :datetime
和 :timestamp
迁移类型都映射到 PostgreSQL 的 TIMESTAMP
数据类型.
这可能是由于定义为标准哈希的固有无序 ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES
常量造成的。当 ActiveRecord 搜索“TIMESTAMP”的第一个合适匹配项时,它可能会意外地找到 :datetime
或 :timestamp
(因为两者都是匹配项)。
简而言之,不要为此大惊小怪,因为这至少不会影响您的数据或架构。
更新
转储中使用的 Rails“数据类型”是使用 simplified_type
方法找到的,该方法将返回 TIMESTAMP 数据类型的 :datetime
。更有可能的是,您升级了 Rails 版本,而之前的版本使用不同的方法来确定数据类型。无论出于何种原因,这都不会对您产生任何影响。
关于ruby-on-rails - Rails 将 schema.rb 时间戳更改为日期时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15528363/