Hi.

The issue is linked with lazy proxies in Hibernate. All proxy objects should initialize their state, if any field besides the @Id is set/get. This is true for my getters, but not for the setters! So, currently I have the following situation: when I load the object from database, the child object loads its content and creates the parent proxy with some id for related entity. So far so good. No lazy initialization occurs.

But after some UI update the UI framework changes the related object (this results in simple change of id field) and setter for ID tries to initialize the proxy and hits the database! WHY?

The error (you can see, that the id setter is invoked and nothing more!):


Pay attention to this line:
com.rstk.kasko.entity.Accident_$$_javassist_19.setId

I use Hibernate 3.5.0 and initialize the proxy id like this:


I very appreciate any help with this issue, it is really strange and seems to be the bug related to this one http://opensource.atlassian.com/project ... e/HHH-3718

Ok, I see, that id setters for proxy require initialization:

BasicLazyInitializer:

(I don't know, why, but let it be this)

So, this means, that it's not permitted to used detached Hibernate objects in UI directly (only for proxies, full fetched objects can be used without restrictions). So, what is the best approach - create clones of Hibernate objects and use them in UI, like Value Objects? I know, it's not very correct to use Data Objects directly in UI, but it was so convenient and no manual work for creating value objects was necessary....

It is not allowed to change the id of an existing object. So even if you can get rid of the LazyInitializationException Hibernate will complain later about the id change. Instead, you'll need to load the object with the new id and change the reference.

Hi. Cannot agree with you.

In my previous projects JSF updated ids and this was saved to database without any problems! The main difference is that I used eager fetching (I didn't manage to enable proxies there, but the parent entities quantity was relatively small and I could afford additional joins), not proxies and worked with detached Hibernate objects (not copies) in my UI. So, the UI framework changed the id of related entity and then I called session.saveOrUpdate(entity) and the entity was saved together with new links to other entities! I didn't have to manage copies, create new referenced objects and so on - the full cycle was: get the entity with its parents, show on UI, let the user edit select html tags to update references (JSF calls setId() on this) and then save the entity to database. Everything is very transparentely and convenient, Hibernate didn't worry about setting Id at all...

But with proxies I see two ways:

1. create deep (!) copies of all just selected entities and give them to UI so that avoid Hibernate lazy initialization on update of reference id.
2. Use jsf request scope instead of view one for UI and use plenty of hidden fields in the page.

Both ways are not good and very burdensome, so it's interesting to know about users experience with proxies in this situation...

I guess you have been lucky if this worked. I can imagine all sorts of problems with this approach. For example, non-unique objects, cascades that overwrite properties for one object with properties from another object, Hibernate complaining about the changed id's. I guess it all depends on the complexity of the update and what else you have been doing with the Hibernate session before.