A detailed description of Cascade properties in Hibernate

When we configure the association, we consider two points: program execution efficiency and actual business needs, in the previous example, whether it is a one-way association or a bidirectional association, we have to use Session.save () for the entity class separately to save the data to the database.
Question: If you save a lot of data, that code is a scary thing.
Is there a simple way?
Cascade=all <set> Tags
Summary: We only persisted to the district object, but through the SQL statement we found that street performed a persistent operation, which is what the Cascade property does. Hibernate persists the associated object when the Cascade property is set to none.


1.all: Cascade operations on all objects Save,update,delete
2.save-update: Cascade operations when saving and changing actions are performed
3.delete: Cascade operation when performing a delete operation
4.none: Do not cascade operations to all operations by default

The settings for the Cascade property often result in performance changes, please set it carefully.
For example, when you save or change an district object, the district object does not necessarily have an associated street object, or the street object does not necessarily need to be updated, but deleting the district object also deletes the street object it is associated with
Therefore: Setting the Cascade property to all is inappropriate and should be set to delete

Hibernate:insert into district (name, id) VALUES (?,?)
Hibernate:insert into Street (name, district_id, id) VALUES (?,?,?)
Hibernate:update Street set district_id=? where id=?
1. First statement: Better understanding, inserting new Area data
2. Next day statement: Why is Insert street there? We didn't write Session.save (street)?
Answer: Actually we set up Cascade Update at district end (cascade= "all")
That is, when hibernate inserts a "new" object record into the district, it checks whether the properties associated with the "District" object (that is, the <set> corresponding property) are changed, and if so, it is manipulated according to what is set. Because the District.getstreet (). Add (street) is called, all hibenate are inserted in district together with the object of the instantaneous state it is associated with to the corresponding table, Central.

Hibernate:update Street set district_id=? where id=?
3. Third statement: Is the UPDATE statement, why repeat the record?
A: Hibernate takes the association between district and the street to District to maintain, in district case, it stores itself, then stores the multiple street that it includes, and then updates each street (update) to itself ( District) is associated.
As far as district is concerned, it does not know whether the street it contains is a stored object, or even if it is a stored object, it is not known whether the district_id on the street table is referring to the ID of the district table
Therefore, it must be updated for all of its included street objects to ensure that the district_id on the street table is pointing to itself.

Because of this, hibernate "is afraid" to perform "District.getstreet (). Add (Street)" When doing so, an unexpected situation occurs (such as Street.getclss=null,street does not belong to the zone)
There is a situation where the foreign key is inconsistent. All occurrences of this redundant UPDATE statement.
That is, the One-to-many secondary (district side) actively maintains the foreign key to ensure that all street objects in the collection containing the district object are associated with their own (district) foreign key.
Popular speaking: Every year new students to report, class teachers actively invite students, rather than students to report. How efficient is it to imagine?
Does hiberate offer any solution to this situation?
Of course there are: that is to set the inverse property!!

A detailed description of Cascade properties in Hibernate