I have a quick question regarding joined-subclasses.
Assuming I have a fairly simple hierarchy:
Code:
class A { }
class B extends A{}
class C extends A{}
My code does a store of a derived class (say class "B"). Then, it attempts to do a load specifying the super class ("A"), I am returned a proxy that is of the super class type (assuming the "B" object is no longer in a session cache).
For example:
Code:
B b = new B();
session.save( b );
session.clear();
Obj copy = session.load( A.class, b.getId() );
The type of the "copy" object is something like:
Code:
com.foo.A$$EnhancerByCGLIB$$1623f325
The proxy is derived directly from A. But, if I look in the CGLIB object at the actual implementation, it is of type "B".
Code:
((HibernateProxy)obj).getHibernateLazyInitializer().getImplementation()
To me, this seems like incorrect behavior, but maybe my assumptions are incorrect. I was under the impression that the proxy should be of the type found in the database. It correctly knows that it is a "B" object since the implementation object found in the proxy is of that type. In fact, the implemenation object now holds information that I can't access via the proxy since it is directly derived off of "A".
The problem appears to be that the proxy is created based on the type that is passed to the load method on session, rather than waiting to create the proxy based on the subclass type that is found when the read on the database is performed.
So, my question is. Is this expected behavior? If yes, why does Hibernate go through all of the trouble to load all of the data for the "B" class instance, and then embed it into a CGLIB proxy that doesn't allow access to that information.
Any help would be greatly appreciated.
--Chris.