0

EF 4.3 Code-First データベースのデータベース作成スクリプトをプログラムで作成したいと考えています。データベースは、標準の DatabaseInitializer メカニズムを使用して正常に作成されますが、次のコードは失敗します。

using(var dc = new MyContext())
{
    var objContext = (IObjectContextAdapter)dc;
    var script = objContext.ObjectContext.CreateDatabaseScript();
}

私が得る例外は次のとおりです。

ストア生成パターン 'Computed' は、タイプ 'timestamp' または 'rowversion' ではないプロパティではサポートされていません。

タイプ「文字列」の定義された計算列がありますが、私が言ったように、データベースは組み込みのDatabaseInitializerを介して作成されたときにうまく作成されます。奇妙なことに、このメソッドを使用して結果として得られるスキーマは、実際には計算列を作成しません。

なぜこれを行っているのかというと、この列を削除して真正な計算列を作成する作成後を実行するスクリプトがあります。EF マッピングで計算された列を指定しないと、挿入時にその列に値を割り当てようとしますが、失敗します。

4

1 に答える 1

1

データベースの作成はさておき、「計算済み」に設定すると、EF はその列の値を書き込もうとはせず、列がクエリされるたびにサーバーによって (おそらく) 計算された値を読み取ることを意味します。EF の観点からは、任意のデータ型の計算列を持つことは有効です。

ここで、EF モデルからデータベースを作成することを検討してください。EF は、データベースに計算列を作成するために何をすべきかを認識していません。実際、列のタイプによっては、特定のデータベースでトリガーなしで作成することさえできない場合があります。そのため、EF4 では、これらの状況で CreateDatabaseScript をスローさせることが決定されました。

ただし、EF 4.3 以降では、SQL Server または SQL Server Compact を対象とする場合、CreateDatabaseScript を使用しなくなりました。代わりに、移行パイプラインを使用します。移行パイプラインについては、データベースの作成が完全に有効なモデルを常にスローするのは間違っていると感じたため、別のアプローチを取ることにしました。特に、データベースに有効な計算列を作成させるためのトリガーまたはその他のメカニズムを追加した移行で独自の SQL を記述できた可能性があることを考慮してください。

これが、データベースが EF 4.3 によって作成されていること (ただし、列を計算するために何もしていないこと) が表示される理由ですが、移行以外の古いメカニズムを使用する CreateDatabaseScript を使用しようとすると、同じモデルがスローされることがわかります。

これを修正する方法は、CreateDatabaseScript を使用する代わりに Migrations にスクリプトを作成させることです。

于 2012-05-31T21:16:54.770 に答える