4

在与其他开发人员合作时，这个问题似乎一直在发生。我们有一个像这样在迁移中创建的表（由 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

这是什么原因造成的？我们应该检查这个修改过的文件还是每次都重置它？

4

1 回答 1

10

这不应该导致任何“重新索引”，因为:datetime和:timestamp迁移类型都映射到 PostgreSQL 的TIMESTAMP数据类型。

这可能是由于ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES定义为标准散列的固有无序常量造成的。当 ActiveRecord 为 'TIMESTAMP' 搜索第一个合适的匹配时，它可能会找到一个:datetime或:timestamp不可预测的（因为两者都是匹配）。

简而言之，不要大惊小怪，因为这至少不会影响您的数据或架构。

更新

转储中使用的 rails 'datatype' 是使用将为TIMESTAMP 数据类型simplified_type返回的方法找到的。:datetime更有可能的是，您升级了 Rails 版本，而之前的版本有不同的方法来确定数据类型。不管是什么原因，这不应该以任何方式影响你。

于 2013-03-20T15:57:17.053 回答