This represents the structure I have not the data or tables.

Hibernate version: 3.0

Mapping documents:
Object A map:



Object B map:



Object A object:



Object B object:






In my application I can modify the list of object B items contained by object A including adding and removing elements to/from the list. After the elements in the arraylist have been modified to satisfaction, the user is able to persist their changes to the database.

If the user deletes an element from the ArrayList, I call the remove method on the array list removing the element from the list and place the object in another list that is used to actually delete the object from the database. All of this seems to work fine EXCEPT when object B has a complex id as above.

Adding elements to B and calling save on object A works fine with the complex id.

When the user chooses to delete an element, I remove the object from the arraylist and build my delete list of objects to be deleted from the database. When it is time to save the data to the database I do the following:


This fails if I have removed objects from the arraylist of object B.

I do have a hashCode and equals methods in object B.

I do this same thing on other objects that do not have a complex id and everything works fine. Unfortunately I do not have the luxury of modifying the database to do away with the complex id.

Any ideas?

How exactly does it fail?
When you do saveOrUpdate for A, Hibernate will try to set shelfId to null in object B that you deleted (since you have cascade to save-update).
Since shelfId is part of a composite id, this might break database consistency (PK unique constraint).

The SQL generated by Hibernate during the saveOrUpdate is essentially trying to set the shelfId to null as you said. Ahhh, if I turn off cascading then I should be okay. I think maybe I have misunderstood the cascade attribute. I have been thinking that setting cascade on for save/update meant that in this case if object A is updated then object B would also be update.

If this is incorrect then will a modification to object B still be recognized if cascade is set to none for the association in A??

Going to try this now.


Michelle

Actually, no.
Hibernate is not setting the field to null because of the cascade="save/update" attribute, but because of the "one-to-many" mapping - this is how it works.
I mentioned the cascade attribute because you can use it to automatically delete the entity B when you remove it from A (by using parent-child mapping, with cascade=all-delete-orphan), and this way you would avoid this problem.