Re: [hibernate-dev] Hibernate 4.0.1: regression with @OneToMany(cascade = CascadeType.REMOVE)
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<steve(a)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.
>
--
steve(a)hibernate.org
http://hibernate.org