First let me state that this looks like and exciting framework.
I do have a concern about the proxy's and nullness. As I understand the framework, it will replace Hibernate's proxy's (which represent lazily loaded parts of the object graph) with null when preparing a given object graph to be sent out of the jvm. My major concern is that null and the proxy stub are not the same thing! Normally in Hibernate null associations mean that the underlying database relationship doesn't exist. If you replace Hibernate's proxys with null, however, doesn't that break the client's ability to do null checking of associations to see if the association exists in the database?
In other words, the LazyInitializationException is actually a good thing. It indicates that a lazily initialized part of the object graph was accessed outside of the session.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Replacing lazy properties with null is the simplest way to send Hibernate "proxyfied" instance through unaware serialization mechanism.
Indeed, that means that the client is in most case not able to know if the association was null or lazy but not loaded.
Nevertheless, the lazy state of the attribute is stored (in ProxyStore class), so when the Hibernate instance comes back on server, the proxy is re-created to have correct Hibernate behavior (that's the merge operation).
We already discuss (on hibernate4gwt forum) on how a client can make the difference between null attribute and lazy one, but I am afraid that there is no simple way (well, there is probably one, in stateless mode only, since the proxy informations are stored on a specific attribute).
If you have any suggestion on how to recreate a LazyInitialisationException on a generic way, I will be glad to discuss about it (and implement it) with you.
Best regards
Bruno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick reply. I'm still thinking about this. But here's what I have so far.
Hibernate does consider the directionality of the underlying DB relationship when materializing object graphs. This is why when an object is loaded and that contains a lazily loaded one-to-one mapping where the foreign key is on the other side of the associations (that has a foreign key to this instead of this has a foreign key to that) hibernate will actually issue another select statement to the database to find out weather that proxy should be null or a proxy.
Therefore, as you are marshalling a given object graph into gwt/dto objects, you can leave nulls alone but getters for things that are Hibernate proxies should throw RunTime exceptions (or a subclass of RuntimeException (GileadLazyInitializationException?) contained in the Gilead .jar) when called. What I don't know is if this would require bytecode instrumentation or just some kind of transformer type pattern.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First let me state that this looks like and exciting framework.
I do have a concern about the proxy's and nullness. As I understand the framework, it will replace Hibernate's proxy's (which represent lazily loaded parts of the object graph) with null when preparing a given object graph to be sent out of the jvm. My major concern is that null and the proxy stub are not the same thing! Normally in Hibernate null associations mean that the underlying database relationship doesn't exist. If you replace Hibernate's proxys with null, however, doesn't that break the client's ability to do null checking of associations to see if the association exists in the database?
In other words, the LazyInitializationException is actually a good thing. It indicates that a lazily initialized part of the object graph was accessed outside of the session.
Hi,
Replacing lazy properties with null is the simplest way to send Hibernate "proxyfied" instance through unaware serialization mechanism.
Indeed, that means that the client is in most case not able to know if the association was null or lazy but not loaded.
Nevertheless, the lazy state of the attribute is stored (in ProxyStore class), so when the Hibernate instance comes back on server, the proxy is re-created to have correct Hibernate behavior (that's the merge operation).
We already discuss (on hibernate4gwt forum) on how a client can make the difference between null attribute and lazy one, but I am afraid that there is no simple way (well, there is probably one, in stateless mode only, since the proxy informations are stored on a specific attribute).
If you have any suggestion on how to recreate a LazyInitialisationException on a generic way, I will be glad to discuss about it (and implement it) with you.
Best regards
Bruno
Hi Bruno:
Thanks for the quick reply. I'm still thinking about this. But here's what I have so far.
Hibernate does consider the directionality of the underlying DB relationship when materializing object graphs. This is why when an object is loaded and that contains a lazily loaded one-to-one mapping where the foreign key is on the other side of the associations (that has a foreign key to this instead of this has a foreign key to that) hibernate will actually issue another select statement to the database to find out weather that proxy should be null or a proxy.
This link discusses this in more detail: http://www.hibernate.org/162.html
Therefore, as you are marshalling a given object graph into gwt/dto objects, you can leave nulls alone but getters for things that are Hibernate proxies should throw RunTime exceptions (or a subclass of RuntimeException (GileadLazyInitializationException?) contained in the Gilead .jar) when called. What I don't know is if this would require bytecode instrumentation or just some kind of transformer type pattern.