スキーマ更新を実行するだけの場合と比べて、Doctrine Migrations の実際的な利点は何ですか?
安全性？
コマンドorm:schema-tool:update（doctrine:schema:updateSymfonyの場合）は警告します
この操作は実稼働環境では実行しないでください。
しかし、なぜでしょうか? 確かに、データは削除できますが、移行でも同様です。
柔軟性？
列のデフォルトなどを追加するためにマイグレーションをカスタマイズできると思いましたが、Doctrine が次の diff でスキーマとコード間の矛盾に気づき、変更を無視してしまうため、うまくいかないことがよくあります。
ベストアンサー1
を使用している場合schema-tool、データベースの変更履歴は保存されません。これは、本番環境やステージング環境では大きな欠点となります。
ライブ プロジェクトに複雑なデータベース構造があると仮定します。次の変更セットでは、何らかの方法でデータベースを変更する必要があります。たとえば、ユーザーの連絡先電話番号は、 ではなく、国コード、市外局番、電話番号のVARCHAR3 つの列という別の形式で保存する必要があります。SMALLINT
まあ、現在のデータを取得し、それを 3 つの値に分割して、それらを挿入し直すクエリを考えるのはそれほど難しくありません。ここで移行が役立ちます。新しいフィールドを作成し、変換を実行して、最後に以前データを保持していたフィールドを削除します。
さらに、down移行で導入された変更を元に戻す必要がある場合は、逆方向のプロセス (移行) を記述することもできます。どこかの誰かがフィールドの形式に大きく依存していてVARCHAR、構造を変更したため、そのコードが期待どおりに動作していないと仮定します。そのため、 を実行するmigration:downと、すべてが元に戻ります。この特定のケースでは、古い列を戻してVARCHAR値を連結し、フィールドを削除します。
Doctrine の移行ツールは、基本的にほとんどの作業を自動的に行います。スキーマを比較すると、必要なupと がすべて生成されるdownので、移行の適用時に破損する可能性のあるデータを処理するだけで済みます。
また、マイグレーションは、チーム内の他の開発者に、スキーマを更新するタイミングを知らせるものです。 だけではschema-tool、チームメイトはプルするたびに を実行する必要がありますdoctrine:schema:update。スキーマが本当に変更されたかどうかわからないからです。
移行を使用する場合、移行フォルダーに何らかの更新があることが常に表示されます。これは、スキーマを更新する必要があることを意味します。