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

问题描述

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

另请注意我的另一个问题我在哪里得出结论，孤儿撤回并不总是按预期工作。现在我开始怀疑，也许级联效果很好，但在此之后，实际的级联删除就像我在这里描述的那样吞并了。 解决方案

<看看这个答案。基本上，JPA规范要求，如果持久操作被应用到被删除的实体上，它将被再次管理。

要验证这是否真的发生，请启用跟踪日志级别 org.hibernate 包和搜索日志条目，如：

  un-调度实体删除... 
  

为避免任何不可预知的行为，建议删除实体的引用是从加载相同会话/事务的所有其他实体实例中删除。

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.

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.

解决方案

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.

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屋！