Hibernate version:
2.1.8
I currently have the following scenario :
Class A manages a list of Class B (all-delete-orphan), and
Class M manages a list of Class N (all-delete-orphan).
B references N (not-null).
Now...if i remove an instance of B from A, it gets deleted because of the cascading. The same holds true for removing N from M.
the problem comes in when I have B' that references N' and I want to delete N.
I would assume it would be as easy as
Code:
A'.getBlist().remove( B' );
M'.getNList().remove( N' );
// commit the session.
Seesm simple enough. But what seems to be happening is that the cascade to N' happens first, putting N' into a deleted state, then the cascade to B' happens and fails.
This is because the doDelete routine first nulls out any transient(or deleted) references (N' is now deleted so B's ref is nulled). Then calls checkNullability, which fails stating that B's reference to N cannot be null..
Now...Why would we care about the referential integrity of a row about to be deleted?. It doesnt seem to make sense to checkNullability on an object that ii going to be deleted.
Note this is a Hibernate issue not a databse issue. I can manually delete the records from the db in one swoop just fine.
The following DOES work though :
Code:
A'.getBlist().remove( B' );
// flush
M'.getNList().remove( N' );
// commit the session
So..is there any way to control the order that the collections are cascaded to. Or to just fix the problem of verifying object state when deleting ?
Login
FAQ
Search
