Hibernate version:
3.0.5

I am facing a problem with orphan deletion. As long as the application is working with the hibernate-modified collection instance the orphan-deletions happen correctly but if the user replaces the old collection a brand new collection then the collection table gets updated correctly but the orphaned elements (from the old collection) do not get removed from the database.
I came across acouple of posts that had similar issue but in their application they could get away by not creating a new collection but clearing the old one and repopulating it but for me this is not an option as Hibernate is being used remotely and i cannot control the client-side input.
So there would be scenarios where they would be working with the original reference (which they did save but due to the fact that the application runs remotely the Hibernate's modification to the collections is not visible on the client-side and hence if the user updates the original reference then the collection again doesnt have the Hibernate changes.
Idealy Hibernate should be able to recogonize the orphans even if this is not teh originally modified collection. To me the orphan-deletion implementation seems to be incomplete. It works only in limited situations. Anyways it was broken for one-to-one references and was only working for collection references and now it seems that that too is not gurateed to always work.
Does anyone has any suggestions to solve this problem elegantly and does in near future Hibernate plans to provide a more complete implementation of orphan deletion?
I would really appreciate any suggestions on solving this issue. Since I am using Hibernate to manage ORM I really dont want to manage the orphans in my application code.

Ranjee29,

One option is to remove the control over the map from the client side. Instead of returning the map object through a getter provide an api that allows to add/remove children. You may need to return a facade object instead of the real hibernate object.

Another approach is to clone the map into a private object when sending the object over the fence and compare the content of the map when the object comes back. Throw an exception if you can get away with it ;)

If this is not an option you can just find all the orphans in the database and delete them. This can be done with left join query outside of hibernate and would be similar in principle to the garbage collection philosophy in java: don't bother the programmer with things that the computer can handle.

Marius

Well I really dont want to make the Hibernate changes visible on the client-side unless the client has made some fetch request to the server, as this would imply that I have to send back all the inserted objects back on to the client-side and somehow merge this state with the original state of objects on the client-side (which I might not have access to) and also the application does bulk inserts at times for which this solution is even worse.

And also i dont want to do a DB cleaning at scheduled times as that again would not fit into our applications expected functionality, and also there can be too many relationships that can potentially produce orphans.

But anyways thanks a lot for your suggestions. :)

Why not take back a set of the children that you want and use the set function to remove all but those children.


Orginal set is cloned and sent to the caller.
Or/then

the caller returns a set of children that he wants.

original set.retain (set returned by the caller).

Then hibernate should see all the removeall's and then delete the orphaned children

Well I cannot send back the original set till the user explicitly asks for them. Everything if the user first retrieves the object and then works with the retrieved object, but if he just saves the object and then works with the original reference (that doesnot have the hibernate-modified collecton) and later in a new session updates this reference then orphan deletion fails.
Hence problem occurs only in this specified scenario.