私は、ほとんどのフレームワークに移行サポートが含まれていない NodeJS のバックグラウンドを持っています。疑問点がいくつかありますので、ご理解いただければ幸いです。
と を使用して製品のデータ スキーマを定義したnameとしpriceます。
description実行するdb:migrateと、将来の製品には説明が必要になりますが、古い製品はどうなりますか?スキーマを進化させ、無効な古いインスタンスをレンダリングする可能性があるこの種の状況を処理するための正しいアプローチは何ですか?
あなたの質問について：
移行で何が起こるかによって異なります。必要な値がある場合は、古いモデルが後で有効になるように移行する必要があります。そうでない場合は、問題が発生し、古いエントリを更新しようとします。これは、モデルの検証によって更新の試行が拒否されるためです (更新に新しく必要なフィールドが含まれていない場合)。
述べたように、それは依存します。そのように移行すると、新しい列に何らかのデフォルト値が設定されますが、問題ありません。それ以外の場合、古いエントリは NULL に設定されます。
何らかの方法で値を自動生成する方法がない場合、またはデフォルト値を適用できない場合は、はい。
移行で明示的に定義されていない場合、古いエントリは新しい列に対して NULL に設定されます。
ほとんどの場合、移行は UP および DOWN の方法で構築できますが、Downway では、情報の損失に基づいて復元できない可能性のある情報が失われます。したがって、すべての移行を削除することは、データベース全体を削除するようなものです。
しかし、なぜ一度にすべての移行をリセットしたいのでしょうか? データベースが進化するにつれて、それを成長する子供のように扱う必要があります。教育に費やした年数を取り戻すことはできませんが、より良い行動を教えることで、不要な情報を忘れることができます (さらに UP 移行で不要な列を削除します)。
スキーマを進化させ、無効な古いインスタンスをレンダリングする可能性があるこの種の状況を処理するための正しいアプローチは何ですか?
あなたは私を責めるかもしれませんが、それは...依存します;)
次の更新試行でモデルが有効になるようにレンダリングされる場合は、気にする必要はありません。そうでない場合は、移行中に注意するか、ある種のスクリプトまたは便利な試みのいずれかで、それらを再び有効に戻す必要があります。