Hi
we want to know that What are the inheritance mapping models in Hibernate?
Loading
Know the answer? Post it — somebody with the same question will find it here.
Sign in to answer this question
It is the same account you read, post and publish with — and you will come straight back to this page.
Satyapriya NayakPosted Apr 22, 2012, 1:46 PM
Inheritance mapping
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
It is possible to define
subclass,union-subclass, andjoined-subclassmappings in separate mapping documents directly beneathhibernate-mapping. This allows you to extend a class hierarchy by adding a new mapping file. You must specify anextendsattribute 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.Table per class hierarchy
Suppose we have an interface
Paymentwith the implementorsCreditCardPayment,CashPayment, andChequePayment. 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 haveNOT NULLconstraints.Table per subclass
A table per subclass mapping looks like this:
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.
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
The optional
fetch="select"declaration tells Hibernate not to fetch theChequePaymentsubclass data using an outer join when querying the superclass.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
Paymentclass is mapped usingTable per concrete class
There are two ways we can map the table per concrete class strategy. First, you can use
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 toPAYMENTin the example above), is needed to hold instances of the superclass.Table per concrete class using implicit polymorphism
An alternative approach is to make use of implicit polymorphism:
Notice that the
Paymentinterface is not mentioned explicitly. Also notice that properties ofPaymentare mapped in each of the subclasses. If you want to avoid duplication, consider using XML entities (for example,[ ]in theDOCTYPEdeclaration 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
Paymentis usually mapped usingMixing implicit polymorphism with other inheritance mappings
Since the subclasses are each mapped in their own
Paymentis just an interface), each of the subclasses could easily be part of another inheritance hierarchy. You can still use polymorphic queries against thePaymentinterface.Once again,
Paymentis not mentioned explicitly. If we execute a query against thePaymentinterface, for examplefrom Payment, Hibernate automatically returns instances ofCreditCardPayment(and its subclasses, since they also implementPayment),CashPaymentandChequePayment, but not instances ofNonelectronicTransaction.Limitations
There are limitations to the "implicit polymorphism" approach to the table per concrete-class mapping strategy. There are somewhat less restrictive limitations to
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
load()/get()s.get(Payment.class, id)from Payment pfrom Order o join o.payment ps.get(Payment.class, id)from Payment pfrom Order o join o.payment pinverse="true"only)s.get(Payment.class, id)from Payment pfrom Order o join o.payment ps.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult()from Payment pPlease refer the below link
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/inheritance.html
http://www.ibm.com/developerworks/java/library/j-hibernate/
Thanks