Load On Demand And some other links
http://forum.javaeye.com/viewtopic.php?t=824&postdays=0&postorder=asc&start=15
http://www.hibernate.org/41.html
http://www.hibernate.org/36.html
some useful tips:
1.
Large Hibernate bags mapped with inverse="false" are inefficient and should be avoided; Hibernate
can't create, delete or update rows individually, because there is no key that may be used to identify an individual
row.
2.
(5) inverse (optional - defaults to false) mark this collection as the "inverse" end of a bidirectional association
(6) cascade (optional - defaults to none) enable operations to cascade to child entities
3.
Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, Hibernate
may cause constraint violations when it creates or updates the association. To prevent this problem, you must
use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the
discussion of bidirectional associations later in this chapter.
4.
Changes made only to the inverse end of the association are not persisted. This means that Hibernate has two
representations in memory for every bidirectional association, one link from A to B and another link from B to
A. This is easier to understand if you think about the Java object model and how we create a many-to-many relationship
in Java:
The non-inverse side is used to save the in-memory representation to the database. We would get an unneccessary
INSERT/UPDATE and probably even a foreign key violation if both would trigger changes! The same
is of course also true for bidirectional one-to-many associations.
5.
FlushMode: Represents a flushing strategy
/**
* The <tt>Session</tt> is never flushed unless <tt>flush()</tt>
* is explicitly called by the application. This mode is very
* efficient for read only transactions.
*/
public static final FlushMode NEVER = new FlushMode(0, "NEVER");
/**
* The <tt>Session</tt> is flushed when <tt>Transaction.commit()</tt>
* is called.
*/
public static final FlushMode COMMIT = new FlushMode(5, "COMMIT");
/**
* The <tt>Session</tt> is sometimes flushed before query execution
* in order to ensure that queries never return stale state. This
* is the default flush mode.
*/
public static final FlushMode AUTO = new FlushMode(10, "AUTO");
6.
One of the very first things that new users try to do with Hibernate is to model a parent / child type relationship.
There are two different approaches to this. For various reasons the most convenient approach, especially for
new users, is to model both Parent and Child as entity classes with a <one-to-many> association from Parent
to Child. (The alternative approach is to declare the Child as a <composite-element>.)
7.
Hibernate collections are considered to be a logical part of their owning entity; never of the contained entities.
This is a crucial distinction! It has the following consequences:
• When we 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 (eg, 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.
• On the other hand, 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 behaviour 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.
Instead, the default behaviour is that adding an entity to a collection merely creates a link between the two entities,
while removing it removes the link. This is very appropriate for all sorts of cases. Where it is not appropriate
at all is the case of a parent / child relationship, where the life of the child is bound to the lifecycle of the
parent.
8.
一般来说建议双向一对多的关系采用1的一方进行持久化。
16.2. Bidirectional one-to-many
Now that the Child entity is managing the state of the link, we tell the collection not to update the link. We use
the inverse attribute.
<set name="children" inverse=" true">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>
The following code would be used to add a new Child
Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
c.setParent(p);
p.getChildren().add(c);
session.save(c);
session.flush();
And now, only one SQL INSERT would be issued!
9.
The explicit call to save() is still annoying. We will address this by using cascades.
<set name="children" inverse="true" cascade="all">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>
Example: Parent/Child
Hibernate 2.1.7 120
This simplifies the code above to
Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
p.addChild(c);
session.flush();
10.
Using cascading update()
考虑级联更新的情况，hibernate必须知道many一方哪些是更新过的数据。
Well, thats all very well for the case of a generated identifier, but what about assigned identifiers and composite
identifiers? This is more difficult, since unsaved-value can't distinguish between a newly instantiated object
(with an identifier assigned by the user) and an object loaded in a previous session. In these cases, you will
probably need to give Hibernate a hint; either
• define unsaved-value="null" or unsaved-value="negative" on a <version> or <timestamp> property
mapping for the class.
• set unsaved-value="none" and explicitly save() newly instantiated children before calling update(
parent)
• set unsaved-value="any" and explicitly update() previously persistent children before calling update(
parent)
none is the default unsaved-value for assigned and composite identifiers.
11.
We mentioned an alternative in the first paragraph. None of the above issues exist in the case of
<composite-element> mappings, which have exactly the semantics of a parent / child relationship. Unfortunately,
there are two big limitations to composite element classes: composite elements may not own collections,
and they should not be the child of any entity other than the unique parent. (However, they may have a surrogate
primary key, using an <idbag> mapping.)
12.
http://www.hibernate.org/41.html
http://www.hibernate.org/36.html
some useful tips:
1.
Large Hibernate bags mapped with inverse="false" are inefficient and should be avoided; Hibernate
can't create, delete or update rows individually, because there is no key that may be used to identify an individual
row.
2.
(5) inverse (optional - defaults to false) mark this collection as the "inverse" end of a bidirectional association
(6) cascade (optional - defaults to none) enable operations to cascade to child entities
3.
Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, Hibernate
may cause constraint violations when it creates or updates the association. To prevent this problem, you must
use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the
discussion of bidirectional associations later in this chapter.
4.
Changes made only to the inverse end of the association are not persisted. This means that Hibernate has two
representations in memory for every bidirectional association, one link from A to B and another link from B to
A. This is easier to understand if you think about the Java object model and how we create a many-to-many relationship
in Java:
The non-inverse side is used to save the in-memory representation to the database. We would get an unneccessary
INSERT/UPDATE and probably even a foreign key violation if both would trigger changes! The same
is of course also true for bidirectional one-to-many associations.
5.
FlushMode: Represents a flushing strategy
/**
* The <tt>Session</tt> is never flushed unless <tt>flush()</tt>
* is explicitly called by the application. This mode is very
* efficient for read only transactions.
*/
public static final FlushMode NEVER = new FlushMode(0, "NEVER");
/**
* The <tt>Session</tt> is flushed when <tt>Transaction.commit()</tt>
* is called.
*/
public static final FlushMode COMMIT = new FlushMode(5, "COMMIT");
/**
* The <tt>Session</tt> is sometimes flushed before query execution
* in order to ensure that queries never return stale state. This
* is the default flush mode.
*/
public static final FlushMode AUTO = new FlushMode(10, "AUTO");
6.
One of the very first things that new users try to do with Hibernate is to model a parent / child type relationship.
There are two different approaches to this. For various reasons the most convenient approach, especially for
new users, is to model both Parent and Child as entity classes with a <one-to-many> association from Parent
to Child. (The alternative approach is to declare the Child as a <composite-element>.)
7.
Hibernate collections are considered to be a logical part of their owning entity; never of the contained entities.
This is a crucial distinction! It has the following consequences:
• When we 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 (eg, 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.
• On the other hand, 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 behaviour 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.
Instead, the default behaviour is that adding an entity to a collection merely creates a link between the two entities,
while removing it removes the link. This is very appropriate for all sorts of cases. Where it is not appropriate
at all is the case of a parent / child relationship, where the life of the child is bound to the lifecycle of the
parent.
8.
一般来说建议双向一对多的关系采用1的一方进行持久化。
16.2. Bidirectional one-to-many
Now that the Child entity is managing the state of the link, we tell the collection not to update the link. We use
the inverse attribute.
<set name="children" inverse=" true">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>
The following code would be used to add a new Child
Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
c.setParent(p);
p.getChildren().add(c);
session.save(c);
session.flush();
And now, only one SQL INSERT would be issued!
9.
The explicit call to save() is still annoying. We will address this by using cascades.
<set name="children" inverse="true" cascade="all">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>
Example: Parent/Child
Hibernate 2.1.7 120
This simplifies the code above to
Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
p.addChild(c);
session.flush();
10.
Using cascading update()
考虑级联更新的情况，hibernate必须知道many一方哪些是更新过的数据。
Well, thats all very well for the case of a generated identifier, but what about assigned identifiers and composite
identifiers? This is more difficult, since unsaved-value can't distinguish between a newly instantiated object
(with an identifier assigned by the user) and an object loaded in a previous session. In these cases, you will
probably need to give Hibernate a hint; either
• define unsaved-value="null" or unsaved-value="negative" on a <version> or <timestamp> property
mapping for the class.
• set unsaved-value="none" and explicitly save() newly instantiated children before calling update(
parent)
• set unsaved-value="any" and explicitly update() previously persistent children before calling update(
parent)
none is the default unsaved-value for assigned and composite identifiers.
11.
We mentioned an alternative in the first paragraph. None of the above issues exist in the case of
<composite-element> mappings, which have exactly the semantics of a parent / child relationship. Unfortunately,
there are two big limitations to composite element classes: composite elements may not own collections,
and they should not be the child of any entity other than the unique parent. (However, they may have a surrogate
primary key, using an <idbag> mapping.)
12.