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予期しない結果が見つかる可能性があります (両方が一致するため)。

要するに、これはデータやスキーマにまったく影響を与えないはずなので、大騒ぎしないでください。

アップデート

ダンプで使用されるレールの「データ型」は、TIMESTAMP データ型simplified_typeを返すメソッドを使用して検出されます。:datetimeRails のバージョンをアップグレードした可能性が高く、以前のバージョンではデータ型を決定する方法が異なっていました。理由が何であれ、これはあなたに影響を与えるべきではありません。

于 2013-03-20T15:57:17.053 に答える