Just heard back from the sepc lead that this happens exactly according to spec. The expectation is that you clean up all other cascadeable-to references to that removed entity. Otherwise, the flush will cascade PERSIST back to it, canceling out the remove.
I think we should add a flag to make this optional. Of course it will have to be enabled by default to comply with JPA. On Wed 18 Jan 2012 11:45:13 AM CST, Steve Ebersole wrote: > I agree its not the best outcome. But according to the spec it is > unfortunately (imo) exactly what should happen, given its current > wording, in a case where you have not cleaned up references to the thing. > > On Wed 18 Jan 2012 11:39:24 AM CST, Guillaume Smet wrote: >> On Wed, Jan 18, 2012 at 6:31 PM, Steve Ebersole<st...@hibernate.org> >> wrote: >>> Well really the trouble is that you are not managing the >>> associations in >>> memory. I understand the behavior is surprising, but had you simply >>> cleaned >>> up the Person reference from all its associations (as the JPA spec >>> says you >>> have to anyway) you would not have gotten this surprise. >> >> That's what we do in our applications. This is just a unit test to >> show all the cascade features to our developers, what they can do, >> when they fail and so on. >> >> The fact that a delete operation is silently ignored is disturbing IMHO. >> > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
