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.
Table 9.1. Features of inheritance mappings
| 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 |