6

最新のダンプからデータベースを復元し、レーキテストを実行しようとしました。残念ながら、30の移行が保留されていました。私の最初のアイデアは、30個の移行コードのそれぞれをコメントアウトして「rakedb：migrate」を実行することでしたが、もっと簡単な解決策が必要です。Rails2.3.14とPostgresql9.1.3を使用しています。

4

3 に答える 3

6

ダンプからデータベースを復元する場合、schema_migrationsテーブルは残りのテーブルと一緒に復元する必要があります。

これは、schema_migrationsテーブルがバックアップされていない可能性があり、現在の問題につながる可能性があることを示しているようです。

理想的な解決策は、を含むすべてのテーブルが正しく含まれているバックアップを復元することschema_migrationsです。

短期的にはこれを回避する方法を見つけたとしても、長期的には、バックアップスクリプトを変更して、を含む必要なすべてschema_migrationsのテーブルを取得するのが正しい解決策です。

今何をすべきかという点で、理想的な解決策は、データベースからその1つのテーブル（schema_migrations）だけをバックアップし、そのデータを現在ロードしようとしているデータベースにインポートすることです。そうすれば、移行は保留されなくなります。

単純なテーブルダンプとロードスクリプトでそれを行うのは問題ないはずです。単純なpostgresguiPgAdmin （http://www.pgadmin.org/）も、単一のテーブルをダンプしてロードするためのいくつかの基本的なツールを提供する場合があります。

于 2012-05-14T09:51:29.160 に答える
4

ケビンは正しいです。しかし、彼は重要なポイントを逃しています。

バックアップから復元すると、実行する必要のある移行を追跡するschema_migrationsテーブルが復元されます。これらの30の移行が、復元元のデータベースで実行されていた場合、それらは実行されなかったでしょう。

ただし、コードは、バックアップによって表されるデータベースのスナップショットよりも30回先に移行されます。

これは、デプロイしてすぐに本番バックアップを取得した場合に発生する可能性があります。移行は本番環境で実行されていますが、展開前の営業時間前からバックアップを取得しています。私は通常、1日待って、翌日のバックアップを取得するのが好きです。

または、それについて心配する必要はありません。バックアップはこれらの30の移行の前にありますが、その後適用されたため、移行により、スキーマがコードのバージョンと一致することが確認されました。それは良いことです。

汗を流さないでください。バックアップに変更が加えられたら、明日もう一度更新してください。

于 2012-05-14T10:37:21.897 に答える
0

次のように、dbテーブルに欠落している移行のタイムスタンプを手動で追加することもできます。

INSERT INTO "public"."schema_migrations"("version") VALUES ('20201212012345')

これは、移行ファイルの「作成」命令を一時的にアウトコメントするのと同じ効果があります。gitからのデプロイプロセスの一部として移行を実行する場合、コメントアウトすると、それらの変更をgitにプッシュする必要があります。

ステージング/開発環境で作業している場合は、dbを直接修正する方が、それらの変更をプッシュするよりも優れている可能性があり、他のデプロイや開発者を混乱させる可能性があります。

于 2020-12-14T16:06:30.220 に答える