Rails将schema.rb中的时间戳更改为日期时间

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

什么导致了这个问题?我们应该检查这个修改过的文件,还是每次都重置它?
1个回答

10

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

这可能是由于内在的ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES常量无序,它被定义为标准哈希表所致。当ActiveRecord搜索'TIMESTAMP'的第一个合适匹配项时,它可能会不可预测地找到:datetime:timestamp(因为两者都匹配)。

简而言之,不要为此烦恼,因为这不会对您的数据或架构产生任何影响。

更新

转储中使用的rails“数据类型”是通过simplified_type方法找到的,该方法将返回:datetime的TIMESTAMP数据类型。更有可能的是,您已经升级了Rails版本,在先前的版本中具有不同的确定数据类型的方法。无论原因如何,这都不会以任何方式影响您。


太好了!我认为你是对的。postgresql_adapter.rb将两者都映射到时间戳数据类型,因此无法逆向工程原始数据。自从我们创建迁移以来,映射关系没有改变,因此它必须在两者之间随机选择。 - Derek Dahmer

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接