[hibernate-dev] Hibernate 4.0.1: regression with @OneToMany(cascade = CascadeType.REMOVE)

[Steve Ebersole]

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 at 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 at hibernate.org
http://hibernate.org