默默忽略 remove() [英] Silently ignored remove()

问题描述

有实体 A 引用(多对一)实体 B，具有从 B 到 A 的反向(映射)引用.还有 A 到 C 的引用和 C 到 A 的反向引用.当我发出entityManager.remove(A) 然后flush() 时，不会生成删除"！但也没有例外.就像根本没有调用 remove() 一样.为什么会这样?如果在 remove() 之前我们从反向引用 B.listOfA 和 C.listOfA 中提取 A，则按预期生成删除".

There is entity A referring (many-to-one) entity B, with inverse (mapped-by) reference from B to A. Also there is reference A to C and inverse reference C to A. When I issue entityManager.remove(A) then flush(), "delete" is not gerenated! But also there are no exceptions. It's just like no remove() was called at all. Why would that happen? If before remove() we extract A from reverse references B.listOfA and C.listOfA, "delete" is generated as expected.

另请注意我的另一个问题我得出的结论是 orphanRemoval 并不总是按预期工作.现在我开始怀疑级联可能工作得很好，但在真正的级联删除之后，就像我在这里描述的那样吞没"了.

Also note my another question where I came to conclusion that orphanRemoval not always works as expected. Now I am starting to suspect that maybe cascading worked well, but after that actual cascaded removal was "swallowed" like I described here.

推荐答案

看看这个 answer.基本上，JPA 规范规定，如果对已删除的实体应用了持久操作，则该实体将再次受到管理.

Take a look at this answer. Basically, JPA specification mandates that a removed entity becomes managed again if the persist operation is applied to it.

要验证这确实发生了，请为 org.hibernate 包启用跟踪日志级别并搜索如下日志条目:

To verify that this is really happening, enable the trace log level for org.hibernate package and search for log entries like:

un-scheduling entity deletion ...

为避免任何不可预测的行为，建议从加载同一会话/事务的所有其他实体实例中删除对已删除实体的引用.

To avoid any unpredictable behaviour, it is recommended that references to removed entities are removed from all the other entity instances that are loaded the same session/transaction.

这篇关于默默忽略 remove()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！