Hibernate supports the three basic inheritance mapping strategies: table per ...
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html. 1 von
4.
Chapter 9. Inheritance mapping
1 von 4
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
Prev
Next
Chapter 9. Inheritance mapping 9.1. The three strategies 9.1.1. Table per class hierarchy 9.1.2. Table per subclass 9.1.3. Table per subclass: using a discriminator 9.1.4. Mixing table per class hierarchy with table per subclass 9.1.5. Table per concrete class 9.1.6. Table per concrete class using implicit polymorphism 9.1.7. Mixing implicit polymorphism with other inheritance mappings 9.2. Limitations
9.1. The three strategies Hibernate supports the three basic inheritance mapping strategies: table per class hierarchy table per subclass table per concrete class In addition, Hibernate supports a fourth, slightly different kind of polymorphism: implicit polymorphism It is possible to use different mapping strategies for different branches of the same inheritance hierarchy. You can then make use of implicit polymorphism to achieve polymorphism across the whole hierarchy. However, Hibernate does not support mixing , and mappings under the same root element. It is possible to mix together the table per hierarchy and table per subclass strategies under the the same element, by combining the and elements (see below for an example). It is possible to define subclass , union-subclass , and joined-subclass mappings in separate mapping documents directly beneath hibernate-mapping. This allows you to extend a class hierarchy by adding a new mapping file. You must specify an extends attribute in the subclass mapping, naming a previously mapped superclass. Previously this feature made the ordering of the mapping documents important. Since Hibernate3, the ordering of mapping files is irrelevant when using the extends keyword. The ordering inside a single mapping file still needs to be defined as superclasses before subclasses.
9.1.1. Table per class hierarchy Suppose we have an interface Payment with the implementors CreditCardPayment, CashPayment , and ChequePayment. The table per hierarchy mapping would display in the following way: ... ... ... ...
Exactly one table is required. There is a limitation of this mapping strategy: columns declared by the subclasses, such as CCTYPE, cannot have NOT NULL constraints.
9.1.2. Table per subclass A table per subclass mapping looks like this: ... ...
17.05.2012 19:19
Chapter 9. Inheritance mapping
2 von 4
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
... ...
Four tables are required. The three subclass tables have primary key associations to the superclass table so the relational model is actually a one-to-one association.
9.1.3. Table per subclass: using a discriminator Hibernate's implementation of table per subclass does not require a discriminator column. Other object/relational mappers use a different implementation of table per subclass that requires a type discriminator column in the superclass table. The approach taken by Hibernate is much more difficult to implement, but arguably more correct from a relational point of view. If you want to use a discriminator column with the table per subclass strategy, you can combine the use of and , as follows: ... ... ... ...
The optional fetch="select" declaration tells Hibernate not to fetch the ChequePayment subclass data using an outer join when querying the superclass.
9.1.4. Mixing table per class hierarchy with table per subclass You can even mix the table per hierarchy and table per subclass strategies using the following approach: ... ... ... ...
For any of these mapping strategies, a polymorphic association to the root Payment class is mapped using .
9.1.5. Table per concrete class There are two ways we can map the table per concrete class strategy. First, you can use . ... ...
17.05.2012 19:19
Chapter 9. Inheritance mapping
3 von 4
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
... ...
Three tables are involved for the subclasses. Each table defines columns for all properties of the class, including inherited properties. The limitation of this approach is that if a property is mapped on the superclass, the column name must be the same on all subclass tables. The identity generator strategy is not allowed in union subclass inheritance. The primary key seed has to be shared across all unioned subclasses of a hierarchy. If your superclass is abstract, map it with abstract="true". If it is not abstract, an additional table (it defaults to PAYMENT in the example above), is needed to hold instances of the superclass.
9.1.6. Table per concrete class using implicit polymorphism An alternative approach is to make use of implicit polymorphism: ... ... ...
Notice that the Payment interface is not mentioned explicitly. Also notice that properties of Payment are mapped in each of the subclasses. If you want to avoid duplication, consider using XML entities (for example, [ ] in the DOCTYPE declaration and &allproperties; in the mapping). The disadvantage of this approach is that Hibernate does not generate SQL UNIONs when performing polymorphic queries. For this mapping strategy, a polymorphic association to Payment is usually mapped using .
9.1.7. Mixing implicit polymorphism with other inheritance mappings Since the subclasses are each mapped in their own element, and since Payment is just an interface), each of the subclasses could easily be part of another inheritance hierarchy. You can still use polymorphic queries against the Payment interface. ... ... ... ...
17.05.2012 19:19
Chapter 9. Inheritance mapping
4 von 4
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
Once again, Payment is not mentioned explicitly. If we execute a query against the Payment interface, for example from Payment, Hibernate automatically returns instances of CreditCardPayment (and its subclasses, since
they
also
implement
Payment),
CashPayment
and
ChequePayment,
but
not
instances
of
NonelectronicTransaction.
9.2. Limitations There are limitations to the "implicit polymorphism" approach to the table per concrete-class mapping strategy. There are somewhat less restrictive limitations to 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 Polymorphic Polymorphic load()/get() one-to-many many-to-many
table per class-hierarchy
s.get(Payment.class, id)
table per subclass
s.get(Payment.class, id)
s.get(Payment.class, id)
s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult()
table per concrete-class (unionsubclass)
table per concrete class (implicit polymorphism)
(for inverse="true"
only)
not supported
not supported
Copyright © 2004 Red Hat Middleware, LLC.
Prev
Chapter 8. Component Mapping
Top of page
Front page
Next
Chapter 10. Working with objects
17.05.2012 19:19
