There are certain limitations to the "implicit polymorphism" approach to the table per concrete-class mapping strategy. There are somewhat less restrictive limitations to <union-subclass> mappings.
The following table shows the limitations of table per concrete-class mappings, and of implicit polymorphism, in Hibernate.
|
Inheritance strategy
|
Polymorphic many-to-one
|
Polymorphic one-to-one
|
Polymorphic one-to-many
|
Polymorphic many-to-many
|
Polymorphic load()/get()
|
Polymorphic queries
|
Polymorphic joins
|
Outer join fetching
|
|
table per class-hierarchy
|
<many-to-one>
|
<one-to-one>
|
<one-to-many>
|
<many-to-many>
|
s.get(Payment.class, id)
|
from Payment p
|
from Order o join o.payment p
|
supported
|
|
table per subclass
|
<many-to-one>
|
<one-to-one>
|
<one-to-many>
|
<many-to-many>
|
s.get(Payment.class, id)
|
from Payment p
|
from Order o join o.payment p
|
supported
|
|
table per concrete-class (union-subclass)
|
<many-to-one>
|
<one-to-one>
|
<one-to-many> (for inverse="true" only)
|
<many-to-many>
|
s.get(Payment.class, id)
|
from Payment p
|
from Order o join o.payment p
|
supported
|
|
table per concrete class (implicit polymorphism)
|
<any>
|
not supported
|
not supported
|
<many-to-any>
|
s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult()
|
from Payment p
|
not supported
|
not supported
|
Table 9.1. Features of inheritance mappings
