0

最初にEFコードを使用して、デベロッパーdbにサンプルテストデータを取り込むために、依存関係が挿入されたDbイニシャライザとシーダーを使用するdbシードフレームワークを用意しました。EF4.3の外部キー命名規則の取り消し/削除/ロールバックの方法はありますか?

多くのデータをインポートする必要があるため、いくつかのテーブルでは、実際のSQLファイルをINSERT文で使用します。これらのINSERT文のいくつかのために、外部キーを再度有効に続いdiabledする必要があります。

​​

私はEF 4.3にEF 4.2から更新され、これらはもはや仕事ことに気づきました。 EFによって作成されたDBの検査はFKが今の異なった名前が付けられていることを示しています。この命名規則を削除し、元に行くにはどのような方法は

FK_CodeFolder1.Table1Name_CodeFolder2.Table2Name_DbFkColumnName 

ありますか?そうでない場合、これはどのようにknown issue or breaking changeではありませんか?

更新ラディスラフの返信後

ラディスラフは、新しい命名パターンの私の上記の説明は非常に適切ではありませんでした、権利です。私はそれを更新しました。の前の部分。完全な名前空間ではありませんでしたが、エンティティモデルプロジェクトのフォルダ名でした。したがって、フォルダAggregateSet1にWidgetAbcというエンティティがある場合、fkパターンのフラグメントは、だけでなく、AggregateSet1.WidgetAbcになります。

答えて

1

なぜそれが問題であると思われるのですか? IMHOこれはEFの内部動作です。まずコードを使用しています。このアプローチでは、データベースで直接作業することは想定されていませんでした。特に、カスタムデータベーススクリプトの生成を制御できないため、 。

動作を元に戻すことはできませんが、マイグレーションを使用してテーブル定義をコーディングすることができます。AddForeignKeyメソッドでFK制約の名前を付けることができます。

Btw。私はEFv4.3でFK制約の異なる命名パターンを見ています:

FK_DependentTableName_PrincipalTableName_FKColumnName 
+0

私は、名前の生成を制御することに関して意見を異にする必要があります。このAPIは、スキーマ名、テーブル名、カラム名など、SQLで具体化できるすべてのものをネーミングすることを制御します。新しい命名規則が少なくとも公開されていれば、非常に役に立ちます。私たちは幸いです。大部分は、あなたが言ったことを正確に辿るからです。ビュー、インデックス、sprocsなどのカスタムSQLをたくさん作成していないためです。私は新しい移行機能については成熟していますが、なぜこの名前のパターンを変更する必要があるのか​​理解したい。 – danludwig

+0

パターンが変更された理由を知りたい場合は、ADO.NETチームに直接お問い合わせください。 –

+0

FKの名前が変更されたという正式な情報はありますか? FKが4.3より前のバージョンで作成されたときに、データベーススキーマからFKを削除する4.3以降のバージョンで作成された移行を適用すると、これは大きな変化でした。 – vk5880

関連する問題