Bulk closing stale resolved issues

Jesper Steen Møller: I was expecting that the child object would be removed from the database without a rather opaque exception being thrown.

I also wasn't expecting that calling em.remove(child) would have any side affects on parents in the current persistence context. I don't know what's going on underneath, but I assume that some state change in the parent had to be committed after doing nothing but call em.remove(child) which caused the cascade to happen (the PERSIST cascade?). IIRC, this doesn't happen when CASCADE is not set.

As there is no join table in OneToMany, it makes no sense to force client code to call parent.getFooChildren().remove(foo) and then em.remove(foo). IIRC, I tested this in eclipse link as well, and it didn't throw an exception.

Edit: I also doubt that such a requirement (explicit removal from OneToMany collection before child removal) is documented anywhere in the hibernate documentation, where as it certainly is extensively with ManyToMany.

Jesper, thanks for the analysis.

OP: What were you expecting to happen?

Since you are not removing the child from the @OneToMany collection, and since the collection is loaded into memory, Hibernate is right to attempt to persist the child in the (implicit) flush() operation on the parent, effectively resuscitating the child from the remove operation. The exception is due to HHH-5124.

If the desired operation was to force the removal from the collection, you need to call remove() on the collection. For a simple OneToMany with a mappedBy on the child, this seems like an undesired overhead (and will work fine if the collection is not loaded), but if the was using a join table, it would be required anyway.

This is probably related to or a duplicate of HHH-5124.