Hibernate version: 3.0.5

I have a baffling (to me at least :)) situation: Consider the following
class hierarcy:


and the database has the following tables and data:


and the following instance set after some queries:


For the purpose of this discussion, ObjectOfSomeClass is an instance of SomeClass which was loaded as a result of a load/query and its refA
member points to ObjectOfA, an instance of *B* was loaded
and was initialised as a proxy so the real class is the CGLIB enhanced
class.

Now, when an instance of SomeOtherClass is required, and when the
instance has its refB member pointing to the same instance of B that is
in the session cache, the same reference value (1100) is being set
in the instance - that is the enhanced class version.

This is not a problem except when the following takes place:



The cast fails since the actual type is the enhanced class.
To compound the confusion, sometimes the reference is the
actual type - B.

What gives? I would have thought that since the correct mapping is
provided, whenever a reference to B in an instance of SomeOtherClass
is made, interception will ensure that the actual target instance is
returned.

What am I missing? Any help will be greatly appreciated

Hibernate caches proxies by entity's primary key. If in some query you retrieved instance of SomeClass, where refA is initialized to lazy-loading proxy pointing to instance of class B, all other queries, that must return same instance of B, will instead return same proxy of type A.

I reported same issue today on this forum:
http://forum.hibernate.org/viewtopic.php?t=955817

You may workaround this issue by
1) Using non-lazy associations
2) Using bytecode instrumentation (helps only when walking by associations in mapped classes)
3) Using explicit proxy unwrapping (see interface HibernateProxy)
4) Mix all above

This seems a pretty fundamental problem for models with inheritance
hierarchies and code that performs visitation over the model,
expecting to find certain types. I hope some Hibernate team member
would shed some light on the issue.

As to the work arounds, 1 and 3 above are not really viable in my case
(for 1 because this would pull back huge chuks of my model into memory,
and for 3 because most of the code in question is oblivious to the
persistence aspects of the application in general and Hibernate in
particular). Would you elaborate a bit on point 2 ?

Hibernate contains bytecode instrumentation tool, which enhances persistent classes in a way, that allows to overcome some of the inheritance mapping issues. As I understand, it intercepts access to persistent fields, loads actual object of correct type, and replaces proxy in that field. This allows you to traverse associations in natural way, avoiding crosscutting of the persistence aspect.

See org.hibernate.tool.instrument.InstrumentTask class for futher reference.

Unfortunatety, this approach works only for associations in persistent classes. If you query domain objects by Session.createQuery(), bytecode instrumentation is unable to help you.

I can't see right solution for this problem, that will work in general case. Alas, programming is always related to trade-offs between tools and imagination :)

BTW, the other workaround is to break polymorphic association in persistent classes and use DAO to retrieve associated object directly. Not very nice, but works well.

Hibernate contains bytecode instrumentation tool, which enhances persistent classes in a way, that allows to overcome some of the inheritance mapping issues. As I understand, it intercepts access to persistent fields, loads actual object of correct type, and replaces proxy in that field. This allows you to traverse associations in natural way, avoiding crosscutting of the persistence aspect.

See org.hibernate.tool.instrument.InstrumentTask class for futher reference.

Unfortunatety, this approach works only for associations in persistent classes. If you query domain objects by Session.createQuery(), bytecode instrumentation is unable to help you.

I can't see right solution for this problem, that will work in general case. Alas, programming is always related to trade-offs between tools and imagination :)

BTW, the other workaround is to break polymorphic association in persistent classes and use DAO to retrieve associated object directly. Not very nice, but works well.

The runtime proxies generated by Hibernate provide *polymorphic* behavior (and no, typecasting does *not* constitute polymorphic behavior nor does instaceof). Consider the low-level details here; when you load your ObjectOfSomeClass which has a lazy polymorphic association to the A/B hierarchy, Hibernate needs to put *something* into the loaded ObjectOfSomeClass. But, as it does not yet have access to the data relating to the A/B association (remember, it is lazy) the best it can do is a proxy typed to the root of the hierarchy

Steve,


I get this, I think - Hibernate attempts to save a trip to the DB and so
it uses only the ID which is used as an FK in the referring object and
whatever meta data information it has about the type of the reference,
here the base of the hierarchy.

OK, so there's no way for Hibernate to determine the right proxy type
during the first reference action, and subsequently, the target of the proxy
is indeed set to an object of the right type. Also, I did not mean to imply
that the Hibernate proxies are not exposing polymorphic behaviour or that
invoking methods on the objects is not the way to do it.
However some of my methods use the base class versions of these objects, in order
to allow all classes in a hierarchy to be manipulated. Some such
manipulation is obviously type specific and so down casting is required.
Moreover, the code is completely persistence agnostic and has no
way of knowing that the objects are really proxies, nor does it care.

So what is a recommended solution while working with persistent objects
like this? How do I get to the target of the proxy, which is of the RIGHT
type without interspersing the code with Hibernate proxy manipulation methods?

lookup visitor pattern at hibernate.

I did, but it seems excessive to just do this conversion. Imagine this bit
of code:


In the above example, a path can connect any two types of NEs
and the code above is typical of several code fragments that, depending
on use case, would be manipulating different kinds of NEs and it would
be a lot less maintainable if the code needed to invoke the visitor
pattern (which is used extensively in other parts of the application)
just to coerce to references to be of the right type.

Is there a way to get Hibernate to attempt to resolve the actual type
by using the database (I do not mean by way of setting proxy = false,
as this would load large chunks of the database into memory) ?

"Moreover, the code is completely persistence agnostic ... "
It is not so practical, there are some limitations like this or multithreading, code cant not be 100% "transparent" in practice.

"So what is a recommended solution while working with persistent objects
like this? "
I prefer to map "discriminator" as simple property.

BTW, you can weave resolving of lazy many-to-one references in the persistence agnostic code by using AOP approach. It's easy to do it via AspectJ or something similar like JBoss AOP Framework. The latter one is very useful approach, because you can develop and test your persistence agnostic code within conventional IDE, but let container to weave in persistence-specific code at load time. We have successfuly prototyped such technique and currently consider applying it in the production code.

I fetch

String query = "from SomeOtherClass c where c.refB.class = my.refB.subClass"

Shouldn't CGLIB and Hibernate have enough info to proxy the association as a being a refB?


Cheers,


:Luiz.


PS: Another question:

Why not fetch the discriminator by default for Entities mapped in a tree?
this whould enable to proxy to the exact subclass allowing casting at runtime wouldn't it?

No. AFAIK, Hibernate is unable to extract type information from such HQL queries. There is simply no place, where it can be stored.

Anyway, constraining type of fetched entity using query doesn't imply, that you will use associated entity in your code. If this is not the case and you indeed want to follow refB association after fetching c, then you can eagerly fetch it with along with c, using JOIN FETCH clause. In this case, refB will refer to instance of valid class.



I'm afraid, eager fetching of discriminator values for associated entries will slow down query execution the same way, as if actual associated entities are fetched eagerly, therefore, eliminating benefits of lazyness. Especially, if inheritance hierarchy is mapped using joined-subclass instead of discriminator values. So, field-level "no-proxy" lazyness is the only performance-efficient solution - of course, at the cost of additional postprocessing step.

Tnx for your reply mate.

Actually, maybe the Hibernate should be able to gather this kind of info from queries !

But i'd like more to have an enhancement to provide typeCasting in a cenario where you have:

.polymorphism on a table-per-hierarchy mapping.
.fetching the id and the discriminator in the the proxied associated entity.
.Would this be as bad as you pointed? Bring just a discr field together with an id?

I think it would be better than using a field "no-proxy" cos' after a typeCasting you get a full load of your proxied entity.


I'm i fooling away in all this? Am i lacking any concept?


Cheers,


:Luiz.

Such functionality can be easy achieved, if you will mark your associations as lazy="none" :)

From the RBDMS standpoint there is almost NO DIFFERENCE, between fetching one field and fetching all fields. Important point here is that determining type of the associated entity in table-per-hierarchy mapping requires joining additional table, which is infeasible from performance standpoint in most cases. Note, that when Hibernate loads entity from DB, it only queries tables, related to that entity's class. Tables, related to lazily associated entities are not even touched.

In other cases, as I said, lazy="none" or JOIN FETCH clause can be used.