3

複合キーを持つ依存オブジェクトのカスケード削除に問題があります。具体的には、EF によって発行された SQL 命令は、依存エンティティの前に主エンティティを削除しようとします。

OnDelete="Cascade"EF モデルの CSDL と SSDL の両方を設定し、従属エンティティをメモリに明示的に読み込んでいるため、EF はそれらを処理することができます。これは別の FK リレーションシップで正しく機能しており、EF は原則を削除する前に子エンティティを正しく削除します。

ただし、この場合はそうではなく、依存エンティティに複合キーがあるためだと思われます。スキーマを簡単に見てみましょう。

Entity A              Entity B                 Entity A_B
  ID (PK)               ID (PK)                  A_ID  (PK, FK to A)
                                                 B_ID  (PK, FK to B)

エンティティ A を削除すると、エンティティ A_B のエントリも削除されます。

ObjectStateManager を調べると、A の A_B エンティティがメモリに読み込まれ、削除対象としてマークされていることがわかりますが、EF は、 A_B を削除する前にA を削除する SQL コマンドを発行します。これは、依存エンティティが独自の PK を持っている場合は正常に機能しますが、複合キーの場合はうまくいかないようです。削除をカスケードする必要があることを EF の FK アソシエーション (SSDL と CSDL の両方) に明示的に伝えても、最初に子を削除しません。

ここでも、A とその A_B の両方がメモリにロードされており、ObjectStateManager はそれらをすべて削除するようにマークしています。プロキシ作成を有効にして POCO を使用していますが、Context に対する LoadProperty 呼び出しを介して子エンティティをメモリに明示的にロードしています。

誰もこれを見たことがありますか？複合キーが本当に問題なのか、それとも単なる気晴らしなのか? あるケースでは EF が SQL コマンドを正しい順序で処理し、別のケースでは処理しないのはなぜですか?

編集: OnDelete ( http://msdn.microsoft.com/en-us/library/cc716734.aspx ) と Relationship Management ( http://msdn.microsoft.com/en-us/ ) の両方のドキュメントを読みました。ライブラリ/ee373856.aspx )。「識別関係と非識別関係に関する考慮事項」というタイトルのセクションは、私がやりたいことが可能であり、実際に期待されていることを暗示しているようです。おそらく、データベースの EF プロバイダー アセンブリ内の何かでしょうか? 私は、SQL Server データベースではなく、IBM.Data.DB2 アセンブリを使用して Informix データベースに対して作業しています。

(さらなる更新: IBM DB2 v9.7fp3a および EF Providers Beta Refresh に更新しました -- http://www.ibm.com/developerworks/forums/thread.jspa?threadID=345634&tstart=0 )

4

1 に答える 1

0

フレームワークによって飲み込まれているエラーがあるかもしれません - それは時々起こります。DB2用のSql Profilerに相当するものがあると思います...私はdbのアクティビティをプロファイリングし、そこで何が起こっているかを確認します。delete の呼び出しがまったく表示されない場合は、少なくともエラーの可能性が 1 つ排除されています。

于 2011-01-10T20:27:12.280 に答える