Proper implementation of cascading operations in an association relationship in hibernate (cascading)

relational database system itself is more complex, plus hibernate O/R mapping layer, complexity increased, very easy to appear problems, I will recently encountered problems and solutions to do a summary, sorted in the following series of articles

Correct understanding of the use of Hibernate aggregation types (collection)

Proper implementation of cascading operations in an association relationship in hibernate (cascading)

Writing persistent object classes in the Hibernate framework some considerations for implementing foreign key correlation

This is the second article that explains the declarative approach to the Cascade attribute in One-to-many (One-to-many) and Many-to-one (many-to-many) relationships. The most critical points in the use process are: There's a persistent object in mind. The tree and its state diagram (states are: Transient, persistent, Detached), when there is an association between objects, if the cascading operation attribute is used, the root object of the tree is found (so to use the tree, Instead of graphs, the cascade is done in single direction, from root to subordinate.

We use the first example again, in order to reflect the correlation between the two, we declare the following One-to-many relationship for the user class

<class name="User" table="USER">
...
<set name="preferences"
cascade="all,delete-orphan"
inverse="true">
<key column="USER_ID" not-null="true"/>
<one-to-many class="Preference"/>
</set>
...
</class>

For the preference class, declare the following many-to-many relationship

<class name="Preference" table="PREFERENCE">
...
<many-to-one name="user" column="USER_ID" not-null="true"
foreign-key="ALLPREFERENCES" class="User"/>
...
</class>

Visible from above, user is root (root) in the relationship tree of user and preference, and a foreign key that declares a not-null for preference is also seen. After the sequential relationship of the cascade is clear, subsequent persistence can only be done to the user, and the preference persistence is accomplished by cascading operations.

According to Hibernate's principles and official recommendations, the following persistence methods should be used:

Session.save (): is used to persist the object of the transient state and its cascading objects (that is, in the session, in the persistent state), for example, to create a new object and its associated.

Session.flush () or transactional commit (commit): a persistence that modifies an object in a presistent state, for example, from a database to a tree in Hibernate, and then to the library again.

Session.update (), Session.saveorupdate (), Session.merge (): Typically used only for persistent operations that are modified after an object in the detached state (this is an important feature of the Hibernate, It's good to handle business-level transactions (transaction) with database-level transactions, and of course, there's nothing wrong with these methods in the last case.

Session.delete (): Deleting objects

After the implementation of the above can not guarantee the proper implementation of the cascade operation of the association relationship, and further analysis of the following articles.

In practice, it is easy to trigger the following exceptions:

Org.hibernate.ObjectDeletedException:deleted object would is re-saved by cascade (remove deleted object from associations ): XXX

This is mainly due to the relationship between the cascade, according to this article and the next article introduced methods can be excluded.

There is also an exception:

Cannot delete or update a parent ROW:A FOREIGN KEY constraint fails ([Definition of foreign key])

The solution is the same.