静默地忽略remove（）

存在实体A引用（多对一）实体B，从B到A的反向（映射）引用。还有参考A到C和反向参考C到A. 当我发出entityManager.remove（A），然后flush（），“删除”不gerenated！但也没有例外。就像没有调用remove（）一样。为什么会发生？如果在删除（）之前，我们从反向引用B.listOfA和C.listOfA中提取A，则按预期生成“delete”。静默地忽略remove（）

另请注意my another question在那里我得出的结论是孤儿删除并不总是按预期工作。现在我开始怀疑，也许级联效果很好，但在此之后，实际的级联拆除就像我在这里描述的那样“吞食”了。

来源

2016-01-17 Maksim Gumerov

发布实体映射以及删除逻辑将有所帮助。您可能需要检查您是否正在实体管理器上启动并提交事务。 –

孤儿去除应该只适用于私人拥有的实体。如果你的'孤儿'与它有其他关系，那么这些关系就必须被清除 - JPA不会为你做。如果这些关系中的任何一个具有级联设置，则可能会导致此类问题。删除其他人引用的对象而不修复这些引用会导致在处理JPA缓存时出现各种问题。 – Chris

看看这个answer。基本上，JPA规范规定，如果对其应用持久性操作，则会再次管理已删除的实体。

要验证这一切真的发生，启用org.hibernate包跟踪日志级别和搜索类似的日志条目：

un-scheduling entity deletion ...

为了避免不可预知的行为，建议对去除实体引用都被删除来自加载相同会话/事务的所有其他实体实例。

来源

2016-01-17 20:37:51

然后你必须说A被安排删除，但是JPA重新考虑了，因为我再次打电话给em.persist（A）。但我根本不打电话坚持（）！我做的唯一的事情就是em.remove（A），然后是em.flush（）。或者你的意思是坚持（B）并坚持（C）无论如何因为删除（A）以某种方式触及B和C（即使我没有明确修改它们）？好的，我会检查。 –

@MaksimGumerov在刷新时，持久化操作级联到来自持久化上下文中存在的所有实体的所有关联。 –

静默地忽略remove（）

回答

相关问题