1

もともと、製品ショットの画像パスを追跡するために配列を使用したいと考えていました。この列を、「在庫」テーブルを参照する別の「画像」テーブルに置き換えることにしました。これにより、一意性を確保するために、自動インクリメント 'image' 'id' をイメージ名の一部として使用できます。

「image_paths」列を削除してから、さまざまな列を持つ新しい「images」テーブルを作成する移行を行いました。新しいテーブルを定義した移行の 2 番目の部分でタイプミスがありました。移行を実行すると失敗しましたが、「image_paths」列は削除されました。移行が登録されていないため、ロールバックできません。また、存在しない列を削除しようとするため、移行を再度実行することもできません。

「image_paths」列を手動で追加してから移行を実行するのが最善の策ですか? 今後、移行ごとに複数のテーブルを変更することは避けるべきですか?

4

2 に答える 2

2

ここで私の提案、

  1. 基本的に 2 つの方法がup()ありdown()ます。up() と一緒に down() を実装することを忘れないでくださいartisan migrate。 which callsに問題がある場合は、 which callsup()でスキーマをロールバックする必要があります。artisan migrate:rollbackdown()

  2. ジョブごとに 1 つとして多くの移行に分割します。単一責任の原則に似ています。たとえば、列を削除する必要がある場合は、新しいテーブルを作成し、リレーションシップの新しい外部キーを作成してから、少なくとも 3 回の移行を行います。

  3. ローカルおよびステージングでテストせずに、移行を本番環境で直接実行しないでください。Seederローカルおよびステージングの場合、 (ローカル、ステージング) または(ステージング)があるため、データのバックアップは必要ありませんproduction_data.sql。移行がローカル マシンとステージング マシンで問題なく実行されている場合は、運用環境で問題ありません。本番環境で移行を編集/更新しないようにしてください。自分自身が殺されます。

これらは私が行っていることであり、移行に関する問題は発生していません。

于 2014-11-22T19:12:50.273 に答える
1

  1. これを行う最善の方法は、データベース エントリをバックアップすることです。移行中に複数の致命的なエラーが発生する可能性があります。

  2. 特定のテーブルの列を変更する場合は、最初にすべてを追加してから、不要な列を削除または削除してください。削除はかなり危険な操作であるため、他の可能な操作が完了した後に削除する必要があります。

  3. リスクをさらに軽減するために、複数の操作を異なる移行ファイルに分けることができます。各操作が正常に終了したことを確認してから、次の操作に進みます。

これらのルールに従えば、すべてうまくいくはずです。

于 2014-11-22T02:32:09.603 に答える