Good day!

We have a serious problem using Hibernate.

The case is that we have a Role that is played by a Party. The method call getPlayedBy() on Role results in a (subclass) of Party. The Party-class is subclassed into several classes (including Role itself) differing extraordinary in the amount and sort of attributes.

We succeeded in storing the Role and Party using the <joined-subclass> mapping mechanism. But, when we later read the persistent object, it appears not to be an instance of the specified subclass, but an instance of Party itself (although it is specified as abstract), An 'instanceof' comparison returns false. It seems Hibernate instantiates the wrong class!

We wouldn't like to use the <subclass> mapping, for that would result in a long and wide table with numerous empty fields. In that solutions discriminators are available to tell Hibernate what subclass to instantiate. Instead, we use the <joined-subclass> mapping. As stated: Storing such an object is no problem - it results in a nice ER-diagram, that is pretty good normalized.

Do you recognize the problem and do you see options to solve it?

Greetz,

Erwin

Sounds like you need to understand how Hibernate proxies work.

Gavin (and others),

Thanx for your reply.

OK, I've read the section of the chapter about Improving Performance in the Reference Documentation (Definitely not the chapter I have had read without your hint). The restriction seems to be logical though - namely, that it is due to Java's single inheritence model.

But, we in our domain, we did hide some business methods from the public area by making these methods protected. By making use of interfaces, this way of protection is no longer valid. Is there a refactored solution (best practise) in order to not expose these methods to the outside world? I can imagine more people have experienced the same problem.

Kind regards,
Erwin

You can always avoid proxies by using lazy fetching. Its quite easy.

But why do you need this? You are doing typecasts in business code?? ugghhhh....


Why not just use polymorphism instead.

I thought that lazy fetching always implies using proxies, isn't it? Or did you mean eager fetching?

About using polymorphism:
We use a huge inheritance tree that is only coupled in the top branches (most close to the super-class Entity) The leaves of this tree do not have much in common. Polymorphistic method calls are insufficient to make use of these instances' functionality.