1

PK に代理キーを使用し、別のエンティティ クラス B への FK を含む一意性制約を定義するエンティティ クラス A があるとします。すべて問題ありません。しかし、どこかで、エンティティ クラス A が実際には B のすべてのキー列ではなく、B のキー列のサブセットによって定義されていることがわかりました。

基本的に、シナリオは次のとおりです。いくつかの列を追加し、古い列を削除する前に、古い列と関係の既存のデータによって計算された値を入力します。

表面的には、これは簡単に思えます。データ モデルに変更を加え、新しい移行を追加し、新しい列を追加した後、そのデータ モーションを実行するために必要な T-Sql で Sql() の呼び出しを使用します。古い列を削除する前に。

ただし、クエリで新しい列を使用すると問題が発生するようです。おそらく、移行全体がバッチまたは何かとして実行されるためです。

この例では、追加される新しい列は BName であり、B から Name 列を移入する簡単な演習です。移行の実行前に、BName は A に存在します。

UPDATE [dbo].[A] SET a.[BName] = b.[Name], 
FROM [dbo].[A] a
FULL OUTER JOIN [dbo].[B] b ON a.[BId] = b.[Id]

これにより、次の結果が得られます。

System.Data.SqlClient.SqlException (0x80131904): The multi-part identifier "a.BName" could not be bound.

Sql() に渡すクエリ内で GO コマンドを使用してバッチを分割しようとしましたが、このツールセットではサポートされていません。

System.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near 'GO'.

EFの現在の状態を考慮して、これを回避する最善の方法は何ですか? あちこち検索したところ、スキーマの変更とデータの移動を別々の移行で実行するという提案がいくつか見つかりましたが、この変更の論理的な原子性のために、これはかなり受け入れがたいことがわかりました。EF で 2 つの別々の移行を並行して開発し、同時にソース管理にチェックインできるようにするのに十分苦労することもできるかもしれませんが、組織化のためだけにそれを行うには、多くの不必要な苦痛が予想されます。

編集:価値のあるものとして、EFCF 移行に関するドキュメントは、これがサポートされていることを示しているようです。しかし、私のものはまだ壊れています。ただし、これは私の愚かな間違いであり、フレームワークの欠点ではないことを願っています。

4

1 に答える 1

2

これは、上記のクエリの構文に問題があったようです。少し変更しましたが、これは機能しているようです：

UPDATE [dbo].[A] SET [BName] = [B].[BName]
FROM [dbo].[A]
FULL OUTER JOIN [dbo].[B] ON [A].[BId] = [B].[Id]

このようにテーブル名を直接使用するのは奇妙に感じますが、これを寝かせるという名目でその譲歩をすることができます。

于 2013-06-07T22:33:50.447 に答える