Hi all,

I have search an answer for a while and I didn't found any good way to do it.

I have a complex object, a Deal, that need to be inserted as new at each modification (versionized instead of updated). All modification to the instance and the instance linked to him must also be save as new instead of "updated". In fact there's no update in my system.

Merging data cannot work.

The solution I have found is to make a Deep Clone of the object (that's ok), to delete the ID of all object recursively and to make a save the noId Deal. Hibernate will create new rows for all objects.

The problem here is that if a Deal has some Lazy load instance (always do), the clone will not have a reference to theses objects and the deal will be inserted without the lazy loaded instances.

Is there another way to resolve this problem? I am using JPA/Hibernate.

Best regards,

Etienne

You need to decide what a "clone" is. In my book, a clone means that you take an object and you clone it and each and every attribute in it. (clone to me is typically a deep copy)

If that is the case, then do not lazy load it when you are ready to clone it. There may be a way to tell hibernate to NOT lazy load data when you do a query even though you have it mapped to do so. If there is not, then you could always extend your class with a new class called FullDeal.java. Then have the FullDeal.java mapping class NOT lazy load anything, but point to the same table.

When you want to clone something, you ask hibernate for a FullDeal instead of a Deal.

If this helps, don't forget to rate! :)

Hi,

if the solution was to clone all the tree with a EAGER load before modification, i wouldn't ask this question; I know it would work. But I cannot load the deal all the time I need to see it or to modify it. The application load does not permit to load all the graph of the deal at start, before modifying a value.

The real problem here, to summarize, is that when I remove all children of a deal (like the Recipiants list) I don't know at the time to save if if the the children were removed or if the children were in a Lazy state. In a merge process, I don't know if Hibernate under the hood have a idea of a "dirty/already loaded collection", I guess it should to work properly. But over the hood I don't see any way to get this data, moreover using the JPA interface. This would resolve most of my problem, I could then EAGER load the Deal at the time of saving it (adding a version), but not at the time of showing/modifying it.

I hope I explain it correctly.

Regards,

Etienne

I am not sure why you would want to know this information - especially if all of your relationships are mapped in hibernate because hibernate will take care of this for you. But you have your reasons which we do not need to get into.


Yes.


Again, not sure why you care.


If you want to know if something has children, and how many children, but the underlying collection is lazy loaded, you could introduce a "formula" to the mapping that simply does a sql count of all the available children. Map that to a Long and then in your logic check to see if the collection contains that number or not.


Why do you care at the time of save? Hibernate handles all of this for you. If your problem is because some other process has the same instance and you are concerned that the data it has is stale, then you will need to introduce versioning on your child objects.

Thanks for your answer, it might help.

The reason I care about the dirty collection is that my requirements is to "never update" a deal, but create a "new deal" with an incremented version number (version 2). The "old deal" must still be there untouched (version 1).

I know, Hibernate might not be the ideal tool to do this job because it does a lot of useful thing under the hood.

So the "pattern" is to insert a new deal whenever I need to "update the old one". So, in the process of creating the new deal to insert, when I have a Deal with configured Lazy load collection, I don't know for sure if an"empty collection" is empty because it was lazy load or because it was previously deleted. The answer we found is to put a transient flag on the Entity to indicate if the collection is dirty.

Regards,

Etienne