16

私はDBを構築するためのFluentNHibernateが大好きですが、これまでのところ、私のトラックで私を止めている制限を見つけていません。

ただし、現在のプロジェクトでは、製品ライフサイクルの非常に早い段階で本番環境にリリースする予定であるため、進行するにつれてdbスキーマに多くの小さな変更が加えられると予想しています。

migratordotnetなどのツールを使用して、「移行」におけるこれらのDDLおよびDMLの変更を追跡したいと思います。しかし、私の質問は、これら2つのツール（または同様のツール）を一緒に機能させることは可能ですか？

DRYの精神で、Fluent Nhibernateのマッピングからスキーマの変更をどのように導き出すことができますか？これは可能ですか？

または、スキーマ生成をmigratordotnetなどのツールに任せ、Fluent NHibernateにマッピングのみの責任を任せるためのより良いアプローチはありますか？うーん、これはツールレベルでの関心の分離のように思えます。

乾杯！

4

4 に答える 4

7

ゴードン、

以前のプロジェクトでも同じ質問がありましたが、データベースの移行にのみ migratordotnet を使用し、SchemaUpdate を完全にスキップすることにしました。

簡単なプロトタイプには引き続き SchemaUpdate を使用しますが、プロジェクトを本格的に開始すると、migratordotnet のみを使用します。

Nightly ビルドの一部として実行する移行セットアップにより、1 つのプロジェクトで複数の人が作業する場合、migratordotnet は非常にうまく機能します。

于 2009-06-03T20:07:14.183 に答える
2

また、(migratordotnet を使用して) 移行とマッピング ファイルを個別に維持する必要がない、この同じ問題に直面しています。これまでのところ、NHibernate の SchemaUpdate だけが役に立ちましたが、これは列やテーブルの削除を処理しません。これらのタイプの変更については、移行を手動で記述する必要があります。現在、SchemaUpdate 生成 DDL と移行を混在させるのではなく、データベースの変更にのみ migratordotnet を使用することに傾いています。ただし、マッピング/ドメインレイヤーの変更を移行に誤って変換する可能性があるため、これはまだエラーが発生しやすいようです。

于 2009-06-03T15:00:17.190 に答える
1

私は同じ問題に直面しています。SchemaUpdate を回避する現在のワークフローは次のとおりです。

  • データベースをゼロから構築する (変更があった場合)
  • すべての参照データをスプレッドシートに保持する
  • 特別なコマンドライン「dataloader」プロジェクトを介してすべてのデータをリロードします

このワークフローは開発に適しています。毎回 DB をゼロから再構築してデータを入力することで、データベースのバージョン管理の問題が解決されるからです。また、DB と挿入する実際のデータをテストするための優れた基盤も提供します。

ライブデータベースが実行されていると、削除して再構築することはできません。これは私がやっていることです：

  • 開発サイクルが完了したら、本番データベースのクローンを作成します。製品データベースは、アップグレード期間中読み取り専用になります (私のアプリでは問題ありません...もっと時間が重要なアプリについてはわかりません)
  • SQL Compare を使用して、dev データベースから prod データベースに変更とデータを移行します。
  • これを押してテストします。
  • テストに合格したら、本番環境にプッシュします。

これは理想的ではなく、商用の SQL Compare 製品を利用します。それは私のために働いていますが、もっと良いアイデアを聞きたいです。

于 2009-12-21T17:03:49.207 に答える
0

はい - ほとんど。シックデスクトップクライアントに使用されている FNH と migratordotnet の両方をうまく使用しており、非常にうまく機能しています。私は2つのことのためにそれを変更しなければなりませんでした:

  1. SQL 接続を TransformationProvider (より正確には SQLiteTransformationProvider) に注入できるようにするには

  2. 他の非 sqlite TransformationProviders への参照を取り除きます。これは、アプリでパッケージ化しようとすると、Oracle、Postgres などを見つけることができないというさまざまなエラーがスローされるためです。

  3. これは sqlite 固有のものです - sqlite create table ステートメントをより適切に解析するためにハックしてください。残念ながら、フォームの create table ステートメントを処理することはできませんCREATE TABLE FOO(id INT, ..., primary key(id))(処理するものとは対照的にCREATE TABLE FOO(id INT PRIMARY KEY, ...))。これを、列の削除を実行する方法 (新しいテーブルの作成、列のないデータの転送、元のデータの削除、新しい名前を元の名前への変更) と組み合わせると、主キー列を作成するテーブルでの列の削除などのかなり厄介な動作が発生する可能性があります非主キー列。

于 2010-08-30T12:34:32.700 に答える