Java Designer: Hibernate Mappings

Learning Notes –

Parent/Child Relationships

Component-element -> Declare as Child
One-to-Many (Entity Relation)-> Association from Parent to child

Component-Element
A component is a contained object that is persisted as a value type and not an entity reference. The term "component" refers to the object-oriented notion of composition and not to architecture-level components

Like value types, components do not support shared references.

<class name="eg.Person" table="person">

Limitation -

Composite elements may not own collections
They should not be the child of any entity other than the unique parent

Entity Relation-

A note about collections

Hibernate collections are considered to be a logical part of their owning entity and not of the contained entities. Be aware that this is a critical distinction that has the following consequences:

When you remove/add an object from/to a collection, the version number of the collection owner is incremented.
If an object that was removed from a collection is an instance of a value type (e.g. a composite element), that object will cease to be persistent and its state will be completely removed from the database. Likewise, adding a value type instance to the collection will cause its state to be immediately persistent.
Conversely, if an entity is removed from a collection (a one-to-many or many-to-many association), it will not be deleted by default. This behavior is completely consistent; a change to the internal state of another entity should not cause the associated entity to vanish. Likewise, adding an entity to a collection does not cause that entity to become persistent, by default.

Adding an entity to a collection, by default, merely creates a link between the two entities. Removing the entity will remove the link. This is appropriate for all sorts of cases. However, it is not appropriate in the case of a parent/child relationship. In this case, the life of the child is bound to the life cycle of the parent.

---------------------------------------------------------------

    <id name="Key" column="pid" type="string">
        <generator class="uuid"/>
    </id>
    <property name="birthday" type="date"/>
    <component name="Name" class="eg.Name"> <!-- class attribute optional -->
        <property name="initial"/>
        <property name="first"/>
        <property name="last"/>
    </component>
</class>

Maintaining the same session across the entire application leads to data inconsistency Session and database.

<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>

<property name="hibernate.connection.url">jdbc:mysql://localhost:3306/cricket</property>

<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.current_session_context_class">thread</property>

<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
<property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>

User --> UserRoles - Many to Many links and Unidirectional

<collection-id type="long" column="ID">

</collection-id>

<many-to-many

class="cricket.hibernate.bf.user.UserRole" column="role_id" />

</idbag>

Roles

Roles –-> Activities -- Many to Many links and Unidirectional

<idbag name="activities" table="ROLE_ACTIVITY_LNK" cascade="all"

access="field" lazy="true">

<collection-id type="long" column="ID">

</collection-id>

<many-to-many class="cricket.hibernate.bf.user.Activity" order-by="priority"

column="activity_id" />

</idbag>

Activities

CoreTeam -- > CoreTeam has many Players

<key column="team_id" />

<list-index column="id" /> --> List Index

<one-to-many

class="cricket.hibernate.bf.team.Player" />

</list>

Player

<many-to-one name="coreTeam"

class="cricket.hibernate.bf.team.CoreTeam" column="team_id"

lazy="false" unique="true" cascade="all" />

UserTeam

<list name="userTeamPlayers" inverse="true" lazy="true"

outer-join="false">

<list-index column="id" />

<one-to-many

class="cricket.hibernate.bf.team.UserTeamPlayers" />

</list>

<many-to-one name="user" class="cricket.hibernate.bf.user.User"

column="USER_ID" lazy="false" unique="true" />

UserTeamPlayers – Link table with some extra attributes

<many-to-one name="userTeam" insert="false" update="false"

not-null="true" column="team_id" />

<many-to-one name="player" insert="false" update="false"

not-null="true" column="player_id" />

TeamShedule - Link table to hold teams and shedule

==> Separate table with separate business functions

<many-to-one name="firstTeam" class="cricket.hibernate.bf.team.CoreTeam"

column="first_team" cascade="none" />

<many-to-one name="secondTeam" class="cricket.hibernate.bf.team.CoreTeam"

column="second_Team" cascade="none" />

PlayerScores

<many-to-one name="match" insert="false" update="false"

not-null="true" column="match_id" />

<many-to-one name="player" insert="false" update="false"

not-null="true" column="player_id" />

PlayerSubstitution - Link table hold old & new players

==> Seperate Table & BO

<property name="userTeamId" column="user_team_id" />

------------------------------------------------------------------------

All indexed collections (maps, lists, and arrays) have a primary key consisting of the <key> and <index> columns. In this case, collection updates are extremely efficient. The primary key can be efficiently indexed and a particular row can be efficiently located when Hibernate tries to update or delete it.

Sets have a primary key consisting of <key> and element columns. This can be less efficient for some types of collection element, particularly composite elements or large text or binary fields, as the database may not be able to index a complex primary key as efficiently. However, for one-tomany or many-to-many associations, particularly in the case of synthetic identifiers, it is likely to be just as efficient. If you want SchemaExport to actually create the primary key of a <set>, you must declare all columns as not-null="true".

<idbag> mappings define a surrogate key, so they are efficient to update. In fact, they are the best case.

Bags are the worst case since they permit duplicate element values and, as they have no index column, no primary key can be defined. Hibernate has no way of distinguishing between duplicate rows. Hibernate resolves this problem by completely removing in a single DELETE and recreating the collection whenever it changes. This can be inefficient.