hibernate笔记， 复习到6.4节

■   Table  per  concrete  class  with  implicit  polymorphism―Use  no  explicit
inheritance mapping, and default runtime polymorphic behavior.
■      Table per concrete class―Discard polymorphism and inheritance relationships completely from the SQL schema.

<hibernate-mapping>
    <class
        name="BillingDetails"
        abstract="true">
        <id
            name="id"
            column="BILLING_DETAILS_ID"
            type="long">
            <generator class="native"/>
        </id>
        <property
            name="name"
            column="OWNER"
            type="string"/>
            ...
        <union-subclass
            name="CreditCard" table="CREDIT_CARD">
            <property name="number" column=”NUMBER”/>
            <property name="expMonth" column="EXP_MONTH"/>
            <property name="expYear" column="EXP_YEAR"/>
        </union-subclass>
        <union-subclass
           name="BankAccount" table="BANK_ACCOUNT">
        ...
    </class>
</hibernate-mapping>

■      Table per class hierarchy―Enable polymorphism by denormalizing the SQL
schema, and utilize a type discriminator column that holds type information.

<hibernate-mapping>
    <class
        name="BillingDetails"
        table="BILLING_DETAILS">
        <id
            name="id"
            column="BILLING_DETAILS_ID"
            type="long">
            <generator class="native"/>
        </id>
        <discriminator
            column="BILLING_DETAILS_TYPE"
            type="string"/>
        <property
            name="owner"
            column="OWNER"
            type="string"/>
            ...
        <subclass
            name="CreditCard"
            discriminator-value="CC">
            <property name="number" column="CC_NUMBER"/>
            <property name="expMonth" column="CC_EXP_MONTH"/>
            <property name="expYear" column="CC_EXP_YEAR"/>
        </subclass>

  </class>

</hibernate-mapping>

Columns for properties declared by subclasses
must  be  declared  to  be  nullable. 

■      Table per subclass―Represent is a (inheritance) relationships as has a (for-
eign key) relationships.

<hibernate-mapping>
    <class
        name="BillingDetails"
        table="BILLING_DETAILS">
        <id
            name="id"
            column="BILLING_DETAILS_ID"
            type="long">
            <generator class="native"/>
       </id>
        <property
            name="owner"
            column="OWNER"
            type="string"/>
            ...
        <joined-subclass
            name="CreditCard"
            table="CREDIT_CARD">
            <key column="CREDIT_CARD_ID"/>
            <property name="number" column="NUMBER"/>
            <property name="expMonth" column="EXP_MONTH"/>
            <property name="expYear" column="EXP_YEAR"/>
        </joined-subclass>
        <joined-subclass
            name="BankAccount"
            table="BANK_ACCOUNT">
        ...
    </class>
</hibernate-mapping>

 

■      If you do require polymorphic associations (an association to a superclass,
hence to all classes in the hierarchy with dynamic resolution of the concrete

class at runtime) or queries, and subclasses declare relatively few properties
(particularly if the main difference between subclasses is in their behavior),
lean toward table-per-class-hierarchy. Your goal is to minimize the number
of nullable columns and to convince yourself (and your DBA) that a denor-
malized schema won’t create problems in the long run.
■      If  you  do  require  polymorphic  associations  or  queries,  and  subclasses
declare  many  properties  (subclasses  differ  mainly  by  the  data  they  hold),
lean  toward  table-per-subclass.

By  default,  choose  table-per-class-hierarchy  only  for  simple  problems.  For  more
complex  cases  (or  when  you’re  overruled  by  a  data  modeler  insisting  on  the
importance of nullability constraints and normalization), you should consider the
table-per-subclass strategy. But at that point, ask yourself whether it may not be
better to remodel inheritance as delegation in the object model. Complex inherit-
ance is often best avoided for all sorts of reasons unrelated to persistence or ORM.

 

concept about custom mapping types: UserType, CompositeUserType…

 

<list name="images" table="ITEM_IMAGE">
    <key column="ITEM_ID"/>
    <list-index column="POSITION"/>

<element type="string" column="FILENAME" not-null="true"/>

</list>

 

对于排序collection有两种思路：

1.

<map name="images"
        table="ITEM_IMAGE"
        sort="natural">

private SortedMap images = new TreeMap();
2.

<map name="images"
     table="ITEM_IMAGE"
     order-by="IMAGENAME asc">

 

Collections of components:

<set name="images"
     table="ITEM_IMAGE"
     order-by="IMAGENAME asc">
    <key column="ITEM_ID"/>
    <composite-element class="Image">
       <property name="name" column="IMAGENAME" not-null="true"/>
       <property name="filename" column="FILENAME" not-null="true"/>
       <property name="sizeX" column="SIZEX" not-null="true"/>
       <property name="sizeY" column="SIZEY" not-null="true"/>
    </composite-element>
</set>