Hibernate example source code file (inheritance_mapping.pot)

This example Hibernate source code file (inheritance_mapping.pot) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - Hibernate tags/keywords

hibernate, hibernate, if, it, mixing, polymorphic, polymorphic, table, tag, tag, the, the, there, you

The Hibernate inheritance_mapping.pot source code

# 
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2010-02-11T05:38:15\n"
"PO-Revision-Date: 2010-02-11T05:38:15\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#, no-c-format
msgid "Inheritance mapping"
msgstr ""

#. Tag: title
#, no-c-format
msgid "The three strategies"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Hibernate supports the three basic inheritance mapping strategies:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "table per class hierarchy"
msgstr ""

#. Tag: para
#, no-c-format
msgid "table per subclass"
msgstr ""

#. Tag: para
#, no-c-format
msgid "table per concrete class"
msgstr ""

#. Tag: para
#, no-c-format
msgid "In addition, Hibernate supports a fourth, slightly different kind of polymorphism:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "implicit polymorphism"
msgstr ""

#. Tag: para
#, no-c-format
msgid "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 <literal><subclass>, <joined-subclass> and <union-subclass> mappings under the same root <class> element. It is possible to mix together the table per hierarchy and table per subclass strategies under the the same <class> element, by combining the <subclass> and <join> elements (see below for an example)."
msgstr ""

#. Tag: para
#, no-c-format
msgid "It is possible to define <literal>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."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Table per class hierarchy"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Suppose we have an interface <literal>Payment with the implementors CreditCardPayment, CashPayment, and ChequePayment. The table per hierarchy mapping would display in the following way:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Exactly one table is required. There is a limitation of this mapping strategy: columns declared by the subclasses, such as <literal>CCTYPE, cannot have NOT NULL constraints."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Table per subclass"
msgstr ""

#. Tag: para
#, no-c-format
msgid "A table per subclass mapping looks like this:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "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."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Table per subclass: using a discriminator"
msgstr ""

#. Tag: para
#, no-c-format
msgid "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 <literal><subclass> and <join>, as follows:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The optional <literal>fetch=\"select\" declaration tells Hibernate not to fetch the ChequePayment subclass data using an outer join when querying the superclass."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Mixing table per class hierarchy with table per subclass"
msgstr ""

#. Tag: para
#, no-c-format
msgid "You can even mix the table per hierarchy and table per subclass strategies using the following approach:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "For any of these mapping strategies, a polymorphic association to the root <literal>Payment class is mapped using <many-to-one>."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Table per concrete class"
msgstr ""

#. Tag: para
#, no-c-format
msgid "There are two ways we can map the table per concrete class strategy. First, you can use <literal><union-subclass>."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Three tables are involved for the subclasses. Each table defines columns for all properties of the class, including inherited properties."
msgstr ""

#. Tag: para
#, no-c-format
msgid "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."
msgstr ""

#. Tag: para
#, no-c-format
msgid "If your superclass is abstract, map it with <literal>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."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Table per concrete class using implicit polymorphism"
msgstr ""

#. Tag: para
#, no-c-format
msgid "An alternative approach is to make use of implicit polymorphism:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Notice that the <literal>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, [ <!ENTITY allproperties SYSTEM \"allproperties.xml\"> ] in the DOCTYPE declaration and &allproperties; in the mapping)."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The disadvantage of this approach is that Hibernate does not generate SQL <literal>UNIONs when performing polymorphic queries."
msgstr ""

#. Tag: para
#, no-c-format
msgid "For this mapping strategy, a polymorphic association to <literal>Payment is usually mapped using <any>."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Mixing implicit polymorphism with other inheritance mappings"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Since the subclasses are each mapped in their own <literal><class> 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."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Once again, <literal>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."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Limitations"
msgstr ""

#. Tag: para
#, no-c-format
msgid "There are limitations to the \"implicit polymorphism\" approach to the table per concrete-class mapping strategy. There are somewhat less restrictive limitations to <literal><union-subclass> mappings."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The following table shows the limitations of table per concrete-class mappings, and of implicit polymorphism, in Hibernate."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Features of inheritance mappings"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Inheritance strategy"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic many-to-one"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic one-to-one"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic one-to-many"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic many-to-many"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic <literal>load()/get()"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic queries"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Polymorphic joins"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Outer join fetching"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "table per class-hierarchy"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><many-to-one>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><one-to-one>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><one-to-many>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><many-to-many>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal>s.get(Payment.class, id)"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal>from Payment p"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal>from Order o join o.payment p"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<emphasis>supported"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "table per concrete-class (union-subclass)"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><one-to-many> (for inverse=\"true\" only)"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "table per concrete class (implicit polymorphism)"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><any>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<emphasis>not supported"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal><many-to-any>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<literal>s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult()"
msgstr ""