Hibernate version: 3.2.0.GA

I have a non-persistent field on a super class of my persistent class. When I call EntityManager.merge() with an instance of my persistent class, the field is reset to its default value in the returned object. Is there a way I can tell Hibernate to copy the correct value over? I wouldn't expect to loose data during a merge().

they have to be persistent

Thanks for the reply. Do you think it is okay for me to open a bug for this?

It don't think it is reasonable to strip out all non-persistent data when doing a merge(). After all, those are POJOs and should have POJO behavior, which is a deep clone in this case.

its a deep clone of the *persistent* data; not of random/all fields.

I understand that, but I think it is inconsistent with what this is trying to be: idiomatic POJO persistence. And this behavior also creates a major problem for me: I am trying to keep track of which new object in a graph is which on the client, but since all non-persistent attributes are wiped out I cannot do that.

so following your reasoning



loadedo should also contain the right values for the transient fields to be what you call "idomatic persistence" - but that does not make sense to save things that are not persistent.

If you want to keep the exact same instance use .saveOrUpdate(); .merge() is for handling the *persistent* state.

In the example you mention transient or non-persistent fields cannot be there. Session.get() asks for a persistent object by its id, which means that the persistent object is loaded from the database, so only persistent fields can be populated.

What I am trying to say is that EntityManager.merge() should behave like Session.saveOrUpdate(), leaving the entire object graph intact, including non-persistent fields. Hm, thinking about this further, it is a little strange that EntityManager.merge() returns the merged graph, instead of simply updating it like Session.saveOrUpdate(). But if I remember correctly, EntityManager.persist() fails if it encounters an already persisted object, right?

I didn't invent the term "idiomatic Java persistence", that comes from Hibernate ;). I just took it to mean a form of persistence that preserves the usual Java behavior wherever possible. In that respect I really like the behavior of Session.saveOrUpdate() in that it simply lets me persist an existing graph without worrying if the objects in it are already persistent or not.

Unfortunately I cannot easily use Session.saveOrUpdate() since we try to stick with the EJB3 API, where EntityManager.merge() seems to be the only equivalent.

yes, but merge != saveOrUpdate.

merge takes the existing *persistent* properties/objectgraph and *merges* into the session - that means any non-persistent part is not available on the returned object....just as with the get operation.

The difference between merge() and get() is that get() retrieves the object by primary key from the database, so there is no way that any non-persistent fields could be populated. But merge() takes an existing graph of objects and could easily perform a deep clone. So why is all the non-persistent data stripped out? I fail to see the benefit of stripping out the non-persistent data, but I know some drawbacks.

why on earth (and how) should hibernate know how to do a deep clone of your objects besides the properties that you have told hibernate how to access/modify ? doing a field by field copy would be the (almost) the same as serializing the object....and how deep should it go for non-persistent associations ? 0 ? 2.5 ? infinite ?

Think about it ...and you will see it makes perfect sense (since the alternative will have much worse consequences)

Once again, thanks for taking the time to reply.

I see your point, I guess the only solution would be a change to the EJB3 standard that brings the saveOrUpdate() functionality into it somehow; or maybe a special annotation that controls the cloning. Since that is unlikely to happen in the near future, should I expect any problems when I get the Hibernate Session from the EntityManager and use saveOrUpdate() from there?

No.