私は最近、あるプロジェクトで Play2 を使い始め、evolutionsのセクションを読みました。私のプロジェクトに 1 つのテーブルがある場合、彼らが引用する例は問題ないように見えますが、10 ～ 20 のテーブルが1.sqlあり、それらへの変更2.sqlが3.sql.
Ruby on Rails、Symfony などでは、エンティティごとにアップ/ダウン マイグレーションを定義します。
私の質問は、Play2 で進化をセットアップする最良の方法は何ですか? すべてのテーブルを1.sql入れてから、それらに少し変更を加える必要が2.sqlありますか? .sqlまたは、テーブルごとに個別のファイルを作成する方法はありますか?
また、大規模なオープン ソースの Play2 プロジェクトで、どのように見えるかを確認できる例はありますか?
実際、Play ではエンティティごとに進化を分割することはできません。
IMHOそれはむしろ好みの問題です.1つの次の進化に各エンティティを追加できます.とにかく、唯一の違いは進化のカウンターが大きくなることです.
典型的なワークフローは、... 適切な計画から始まります。スキーマのグラフ表現を作成し、そこに必要なだけ多くのものを追加してみてください。これは、プロジェクトの開始時や開発の次のステップで大いに役立ちます。
Ebean を使用し、グラフからすべてのモデルを作成し、プラグインに自動の最初の進化ファイルを作成させる場合、関係、制約などの進化を記述する時間を大幅に節約できます。修正とチェックに時間を費やしてください。さらに開発する前の初期スキーマ。
その後、DB全体を削除し、テーブルを最初から再作成するため、自動更新を無効にする必要があります（Ebeanには差分スキーマの更新はありません）。
好みの問題でもありますが、私はいくつかの変更を単一の進化に結合することを好みます (これもまた計画です...)。