I'm trying to find out how to lazily load a subclass when using the table per subclass inheritance mapping using a discriminator column. The reason being, in about half of the time, we don't want or need to access the properties of the subclasses, we simply need the properties from the parent class.

But it seems that, even specifying "lazy=true" on the subclass mapping / element, Hibernate still ( assuming "fetch=select" on the join element of the subclass mapping ) eagerly fetches the data from the table mapped to the subclass as soon as I access just the property from the parent class.

I tried specifying either the subclass or the parent class in the call to load(), hoping that somehow specifying the parent class will give me a lazily loaded subclass:

1) When specifying the subclass in load(), Hibernate uses an inner join against the table mapped to the subclass.

2) When specifying the parent class in load(), Hibernate uses 2 separate SELECTs ( one against the table mapped to the parent class, another against the table mapped to the subclass ).

I was hoping / expecting that Hibernate will only do a separate SELECT from the table mapped to the subclass only when I access / set the properties of the subclass.

What am I missing ?

Below are sample a sample mapping file, SQL scripts, and sample code, and output:

Hibernate version: 3.3.1 GA

Mapping documents:




SQL scripts:



Code between sessionFactory.openSession() and session.close():


Full stack trace of any exception that occurs: n/a

Name and version of the database you are using: Oracle 10G Release 2

The generated SQL (show_sql=true):

When specifying the subclass in load(), an inner join is used when a property of the superclass is accessed via the getPaymentType() method:



When specifying the superclass in load(), two SELECTs are made when a property of the superclass is accessed via the getPaymentType() method:



Debug level Hibernate log excerpt:

Debug level output for the code:


e.g.: When specifying the subclass in load():




Debug level output for:



e.g. When specifying the parent class in load():

So it seems that others who have asked this question:

http://forum.hibernate.org/viewtopic.php?t=930208
http://forum.hibernate.org/viewtopic.php?t=934053
http://forum.hibernate.org/viewtopic.php?t=935155

... appears not to have a solution. What's the point of having / allowing the lazy attribute in the subclass element then ?

Let me rephrase my question:

I actually WANT hibernate to return me the correct subclass. However, I only want hibernate to do a SELECT from the table mapped to the subclass only when I actually access the properties of the subclass. If I only access the properties of the parent class, then there should be no need for Hibernate to SELECT from the table mapped to the subclass, even though Hibernate returned me the correct subclass.

After further thinking about it .... the reason probably why Hibernate does not do what I was expecting it to do is because of the other inheritance strategy, which still uses a table per concrete class but no discriminator. In that case, the only real way for Hibernate to find out what subclass to use is to actually select or do an outer join against the tables mapped to the subclasses.

However, I think the table per subclass using a discriminator can be exception, since Hibernate already knows what subclass to use based on the discriminator value, so that it does not really need to fetch or select from the table mapped to the subclass unless the properties of the subclass are accessed.

I have found an alternative solution, though not the best.

What I have done, using the previous mapping file as an example, is to map the same class twice ( as per http://www.hibernate.org/hib_docs/v3/reference/en-US/html/mapping-entityname.html ), but the second mapping has no subclasses and uses a different entity name.

Here's the updated mapping file using the example from my original post:


Thus, if I want to get a list of Payment without having to hit the tables mapped to the subclasses, I do:



The draw back of this is that instances of objects returned from the list using the PaymentNoInheritance entity name versus instances of objects from Payment are different as far as Hibernate's persistent context is concerned, even though they have same ID ( same row in the database ).