Глава 16. Пример: Родитель/Ребенок (Parent/Child)

Самое первое что новые пользователи пытаются сделать с Hibernate, -- это смоделировать отношение родитель / ребенок (parent / child). Имеется два различных подхода в реализации данного отношения. По многим причинам, один из наиболее удобных подходов, особенно для новых пользователей, это использование двух классов-сущностей (entity classes) Parent и Child с ассоциацией <one-to-many> направленной от класса Parent к Child. Альтернативный подход, это объявление Child как <composite-element> в классе Parent. Но надо заметить, что ассоциация родитель / ребенок (parent / child), замэпленная с использованием <composite-element>, явлеется более близкой к обычной семантики данного отношения. Для более эффективного и элегантного моделирования отношения родитель / ребенок мы рассмотрим как как использовать двунаправленные один-ко-многим каскадные ассоциации (bidirectional one to many association with cascades). Это вовсе нетрудно!

16.1. Примечание о коллекциях

Hibernate-коллекции рассматриваются как логическая часть сущности-владельца (owning entity), но никак не часть содержимых сущностей (contained entities). shl: Т.е. коллекция -- это всегда логическая часть родителя, но не детей! Это определяющая особенность! И она имеет следующие последствия:

  • Когда мы удаляем объект из коллекции или добавляем его в коллекцию, номер версии объекта-владельца коллекции увеличивается на один (т.е. версия родителя инкрементируется).

  • Если объект удаленный из коллекции является экземпляром типа-значение (value type), например композитный элемент (composite element) или java.lang.Long, то данный объект перестает быть долгоживущим и его состояние будет полность удалено из базы данных. Аналогично, добавление в коллекцию экземпляра типа-значение (value type) приводит к тому, что этот объект немедленно становится долгоживущим (persistent) и его состояние будет сохранено в базу данных.

  • С другой стороны, если сущность (entity) удаляется из коллекции (one-to-many или many-to-many ассоциаци), то данная сущность по умолчанию не удаляется из базы данных. Данное поведение является достоаточно последовательным -- изменение внутреннего состояния сущности (entity), не должно приводить к исчезновению другой сущности имеющей связь с изменяемой. Аналогично, добавление сущности (entity) в коллекции не приводит к тому что добавленная сущность становится по умолчанию долгоживущей (persistent entity).

Поведение по умолчанию следующее: добавление сущности в коллекцию, только создает связь между двумя сущностями; удаление сущности из коллекции удаляет данную связь. Данное поведение является приемлемым для большинства сценариев. Если же данное поведение вовсе не подходит, то это и есть сценарий родитель / ребенок, где жизненный цикл объекта-ребенка привязан к жизненному циклу объекта-родителя.

16.2. Двунаправленная один-ко-мрогим ассоцияция (bidirectional one-to-many)

Рассмотрим вначале простую <one-to-many> ассоциацию от класса Parent к классу Child.

<set name="children">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>

Если нам надо выполнить следующий код:

Parent p = .....;
Child c = new Child();
p.getChildren().add(c);
session.save(c);
session.flush();

Hibernate выполнит два SQL-запроса:

  • сначала INSERT создает запись в соответсвующей таблице, для объекта c;

  • затем UPDATE создает связь от объекта p к объекту c.

Данное поведение является ни только неэффективным (два запроса), но и нарушает NOT NULL-ограничение (constraint) на колонке parent_id.

Причина этого в том что связь, внешний ключ (foreign key) parent_id от объекта p к c не рассматривается как часть состояния объекта класса Child и следовательно не создается в INSERT-запросе. Таким образом, решением данной ситуации: сделать связь частью мэппинга класса Child.

<many-to-one name="parent" column="parent_id" not-null="true"/>

Также мы должны добавить свойство parent к классу Child.

Теперь сущность Child управляет состоянием связи, мы конфигурируем коллекцию в классе Parent, такми образом, что бы она не обновляла (update) данную связь, для этого используется аттрибут inverse данной коллекции.

<set name="children" inverse="true">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>

Следующий код может быть использован для того чтобы доваить новый экземпляр класса 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();

Теперь будет выполнен только один SQL INSERT!

Чтобы немного сократить данный пример, мы можем создать в классе Parent метод addChild().

public void addChild(Child c) {
c.setParent(this);
children.add(c);
}

Теперь код для добавления нового объекта класса Child выглядит следующим образом:

Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
p.addChild(c);
session.save(c);
session.flush();

16.3. Cascading lifecycle

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>

This simplifies the code above to

Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
p.addChild(c);
session.flush();

Similarly, we don't need to iterate over the children when saving or deleting a Parent. The following removes p and all its children from the database.

Parent p = (Parent) session.load(Parent.class, pid);
session.delete(p);
session.flush();

However, this code

Parent p = (Parent) session.load(Parent.class, pid);
Child c = (Child) p.getChildren().iterator().next();
p.getChildren().remove(c);
c.setParent(null);
session.flush();

will not remove c from the database; it will ony remove the link to p (and cause a NOT NULL constraint violation, in this case). You need to explicitly delete() the Child.

Parent p = (Parent) session.load(Parent.class, pid);
Child c = (Child) p.getChildren().iterator().next();
p.getChildren().remove(c);
session.delete(c);
session.flush();

Now, in our case, a Child can't really exist without its parent. So if we remove a Child from the collection, we really do want it to be deleted. For this, we must use cascade="all-delete-orphan".

<set name="children" inverse="true" cascade="all-delete-orphan">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>

Note: even though the collection mapping specifies inverse="true", cascades are still processed by iterating the collection elements. So if you require that an object be saved, deleted or updated by cascade, you must add it to the collection. It is not enough to simply call setParent().

16.4. Using cascading update()

Suppose we loaded up a Parent in one Session, made some changes in a UI action and wish to persist these changes in a new Session (by calling update()). The Parent will contain a collection of childen and, since cascading update is enabled, Hibernate needs to know which children are newly instantiated and which represent existing rows in the database. Lets assume that both Parent and Child have (synthetic) identifier properties of type java.lang.Long. Hibernate will use the identifier property value to determine which of the children are new. (You may also use the version or timestamp property, see Раздел 9.4.2, «Updating detached objects».)

The unsaved-value attribute is used to specify the identifier value of a newly instantiated instance. unsaved-value defaults to "null", which is perfect for a Long identifier type. If we would have used a primitive identitifier property, we would need to specify

<id name="id" type="long" unsaved-value="0">

for the Child mapping. (There is also an unsaved-value attribute for version and timestamp property mappings.)

The following code will update parent and child and insert newChild.

//parent and child were both loaded in a previous session
parent.addChild(child);
Child newChild = new Child();
parent.addChild(newChild);
session.update(parent);
session.flush();

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.

There is one further possibility. There is a new Interceptor method named isUnsaved() which lets the application implement its own strategy for distinguishing newly instantiated objects. For example, you could define a base class for your persistent classes.

public class Persistent {
private boolean _saved = false;
public void onSave() {
_saved=true;
}
public void onLoad() {
_saved=true;
}
......
public boolean isSaved() {
return _saved;
}
}

(The saved property is non-persistent.) Now implement isUnsaved(), along with onLoad() and onSave() as follows.

public Boolean isUnsaved(Object entity) {
if (entity instanceof Persistent) {
return new Boolean( !( (Persistent) entity ).isSaved() );
}
else {
return null;
}
}

public boolean onLoad(Object entity, 
Serializable id,
Object[] state,
String[] propertyNames,
Type[] types) {

if (entity instanceof Persistent) ( (Persistent) entity ).onLoad();
return false;
}

public boolean onSave(Object entity,
Serializable id,
Object[] state,
String[] propertyNames,
Type[] types) {

if (entity instanceof Persistent) ( (Persistent) entity ).onSave();
return false;
}

16.5. Conclusion

There is quite a bit to digest here and it might look confusing first time around. However, in practice, it all works out quite nicely. Most Hibernate applications use the parent / child pattern in many places.

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.)