实体框架 - 级联删除复合关键实体时,从属对象不会在主体对象之前删除

发布于 2024-10-04 01:30:02 字数 1711 浏览 11 评论 0原文

我在使用复合键级联删除依赖对象时遇到问题。具体来说,EF 发出的 SQL 指令会尝试在依赖实体之前删除主体实体。

我在 EF 模型的 CSDL 和 SSDL 中设置了 OnDelete="Cascade" ,并显式地将依赖实体加载到内存中,以便 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 会发出 SQL 命令来删除A 删除其 A_B 之前。当依赖实体有自己的 PK 时,这可以正常工作,但当它是复合键时,似乎会出错。尽管我明确告诉 EF 的 FK 协会(SSDL 和 CSDL)删除应该级联,但它不会首先删除子级。

同样,我将 A 及其 A_B 加载到内存中,并且 ObjectStateManager 将它们全部标记为要删除。我正在使用启用了代理创建的 POCO,但我通过针对 Context 的 LoadProperty 调用显式地将子实体加载到内存中。

有人见过这个吗?复合键真的是问题还是只是干扰?为什么 EF 在一种情况下能够以正确的顺序处理 SQL 命令,而在另一种情况下却不能?


编辑:我已阅读 OnDelete 的文档 ( http://msdn.microsoft.com/en-us/library/cc716734.aspx)和关系管理 (http://msdn.microsoft.com/en-us/library/ee373856.aspx)。标题为“识别和非识别关系的考虑因素”的部分似乎暗示我想做的事情是可能的,而且确实是预期的。它可能是数据库的 EF 提供程序程序集中的某些内容吗?我正在使用 IBM.Data.DB2 程序集来处理 Informix 数据库,而不是针对 SQL Server 数据库。

进一步更新:我已更新至 IBM DB2 v9.7fp3a 和 EF Providers Beta Refresh -- http://www.ibm.com/developerworks/forums/thread.jspa?threadID=345634&tstart=0)

I'm having an issue with cascade deletion of dependent objects with composite keys. Specifically, the emitted SQL instructions by EF tries to delete the principle entity before the dependent entity.

I have OnDelete="Cascade" set in both the CSDL and SSDL of my EF model and am explicitly loading the dependent entities into memory so EF knows to handle them. I have this working correctly with another FK relationship and EF correctly deletes the children entities before deleting the principle.

However, it's not in this case and I suspect it's because the dependent entity has a Composite Key. A brief look at the schema:

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

I want the entries of Entity A_B to be deleted when I delete Entity A.

I can look into the ObjectStateManager and see A's A_B entities loaded in memory and marked for deletion, yet EF emits a SQL command to delete A before deleting its A_Bs. This works fine when the dependent entity has its own PK, but seems to get tripped up when it's a Composite Key. It doesn't delete the children first even though I explicitly tell the EF's FK Association (both SSDL and CSDL) that Deletes should be Cascaded.

Again, I have both A and its A_Bs loaded in memory and the ObjectStateManager has them all marked to be deleted. I'm using POCOs with Proxy Creation enabled, though I explicitly load the child entities in memory via LoadProperty calls against the Context.

Has anyone seen this? Is the Composite Key really the issue or just a distraction? Why does EF handle the SQL commands in correct order in one case but not the other?


EDIT: I've read the documentation for both OnDelete (http://msdn.microsoft.com/en-us/library/cc716734.aspx) and Relationship Management (http://msdn.microsoft.com/en-us/library/ee373856.aspx). The section entitled "Considerations for Identifying and Non-identifying Relationships" seems to imply that what I'm wanting to do is possible, and is, indeed, expected. Could it perhaps be something within the EF provider assembly for the database? I'm working against an Informix database using IBM.Data.DB2 assembly and NOT against a SQL Server database.

(Further update: I have updated to IBM DB2 v9.7fp3a and EF Providers Beta Refresh -- http://www.ibm.com/developerworks/forums/thread.jspa?threadID=345634&tstart=0)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

极致的悲 2024-10-11 01:30:02

框架可能会吞掉一些错误——这种情况有时会发生。我认为有一些与 DB2 的 Sql Profiler 等效的东西...我会分析数据库的活动并查看那里发生了什么。如果您根本没有看到对删除的调用,至少您已经消除了错误的一种可能性。

There may be some error that's being swallowed by the framework - it happens sometimes. I presume that there's some equivalent to Sql Profiler for DB2...I would profile the activity of the db and see what's going on there. If you don't see the call to delete at all, at least you've eliminated one possibility of the error.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文