Difference between hibernate update and hibernate saveorupdate

From: http://developer.51cto.com/art/200906/130121.htm

 

This article describes the differences between hibernate update and hibernate saveorupdate. Firstly, it describes the three states of Po, and then focuses on the differences between hibernate update and hibernate saveorupdate.

In hibernate, the core concept is po state management. One Po has three statuses:

1. The non-persistent vo is a memory object Vo, which is managed by the JVM.

2. The persistent Po is mapped to the database data during the session lifecycle and managed by the database.

3. I have been persistent, but now I have already detached the session and run it as VO. This kind of Po with the session already detached can still enter another session, proceed to the PO status management, and then it becomes the second Po status. This type of Po is actually maintained across sessions.

In the traditional jdo1.x, only the first two States of a po are available. Once a po is detached from the PM, it is lost and no longer associated with the database data, making it a pure memory vo, even if it enters a new PM, it cannot be restored.

What makes hibernate strong is that after a po is detached from the session, it can maintain the status and then enter a new session to restore the State management capability. However, in this case, session is required for status management. update or session. saveorupdate, which is the "requires a slightly different programming model" mentioned in the hibernate reference ".

This topic is now officially introduced:

In short, Hibernate update and hibernate saveorupdate are used to manage the status of pods across sessions.

Assume that your PO does not need to be used across sessions. For example, if you open a session, perform operations on the Po, and close the Po, then you will not use this po, hibernate update is not required.

Therefore, let's take a look at the previous example:

Java code:

 
 

  
  
Foo foo=sess.load(Foo.class,id);;      
  
  
foo.setXXX(xxx);;      
  
  
sess.flush();;     
  
  
sess.commit();;      
  
  
Foo foo=sess.load(Foo.class,id);;  foo.setXXX(xxx);;    
  
  
sess.flush();; sess.commit();;  
 
 

The operations on the Po object Foo are completed within the lifecycle of a session, so explicit operations such as sess. Update (FOO) are not required. Hibernate automatically detects that the foo object has been modified. Therefore, it sends a hibernate update SQL statement to the database. Of course, if you want to add sess. Update (FOO), it will not be wrong, but there is no need to do so.

Cross-session means that after the session is closed, you use the Po object as a Vo. Later, you modify its attributes outside the session, then you want to open a session and save the modified VO attributes to the database. Then you need to use hibernate update.

Java code:

 
 

  
  
// in the first session      
  
  
Cat cat = (Cat); firstSession.load(Cat.class, catId);;      
  
  
Cat potentialMate = new Cat();;      
  
  
firstSession.save(potentialMate);;         
  
  
// in a higher tier of the application      
  
  
cat.setMate(potentialMate);;         
  
  
// later, in a new session      
  
  
secondSession.update(cat);;    
  
  
// update cat      
  
  
secondSession.update(mate);;   
  
  
// update mate     
  
  
// in the first session  Cat cat = (Cat); firstSession.load(Cat.class, catId);;  
  
  
Cat potentialMate = new Cat();;  firstSession.save(potentialMate);;     
  
  
// in a higher tier of the application  cat.setMate(potentialMate);;     
  
  
// later, in a new session  secondSession.update(cat);;    
  
  
// update cat  secondSession.update(mate);;   
  
  
// update mate 
 
 

The cat and mate objects are obtained in the first session. After the first session is closed, the cat and mate objects become the third state of the Po, and the Po with the session already detached, their status information is retained. When they enter the second session, they can immediately update the status. But because of the cat Modification Operation: cat. setmate (potentialmate); is performed outside the session. hibernate cannot know that the cat object has been modified. The second session does not know the modification. Therefore, it is necessary to explicitly call secondsession. update (CAT); Notify hibernate that the cat object has been modified. You must send the hibernate update SQL statement.

Therefore, Hibernate update is used only when a po object synchronizes status across sessions. A po object does not need to write hibernate update when it does not need to perform status management across sessions.
Let's talk about the use of hibernatesaveorupdate:

The difference between hibernate saveorupdate and hibernate update lies in what policies does hibernate adopt for Po in cross-session Po state management.

For example, when you write a daoimpl, add a mate to the cat object, as defined below:

Java code:

 
 

  
  
public void addMate(Cat cat, Mate mate); {     
  
  
     Session session = ...;     
  
  
     Transacton tx = ...;     
  
  
     session.update(cat);;     
  
  
     cat.addMate(mate);;     
  
  
     tx.commit();;     
  
  
     session.close();;     
  
  
};     
  
  
public void addMate(Cat cat, Mate mate);   
  
  
{     Session session = ...;       
  
  
Transacton tx = ...;     session.update(cat);;       
  
  
cat.addMate(mate);;     tx.commit();;       
  
  
session.close();; }; 
 
 

Obviously, you need to encapsulate hibernate operations in Dao, so that programmers at the business layer and programmers at the web layer do not need to understand Hibernate and directly call Dao.

At this point, the problem arises: The above code runs correctly and there is a necessary premise, that is, the cat object of the method call parameter must be a persistent Po, that is, it should be first queried from the database before it can be used in this way. But the programmer at the business layer obviously does not know this kind of internal mystery. If his business is to add a cat and then add its mate, he will obviously call it like this, after a new cat object is created, addmate:

Java code:

 
 

  
  
Cat cat = new Cat();;     
  
  
cat.setXXX();;     
  
  
daoimpl.addMate(cat,mate);;     
  
  
Cat cat = new Cat();; cat.setXXX();;   
  
  
daoimpl.addMate(cat,mate);; 
 
 

However, please note that this cat object is only a Vo, it has not been persisted, it is not a po, It is not qualified to call the addmate method, therefore, calling the addmate method does not actually send an update SQL statement to the database. This cat object must be saved to the database first and be eligible for addmate only after it becomes a po.

You must perform the following operations:

Java code:

 
 

  
  
Cat cat = new Cat();;     
  
  
cat.setXXX();;     
  
  
daoimpl.addCat(cat);;     
  
  
daoimpl.addMate(cat, mate);;     
  
  
Cat cat = new Cat();;   
  
  
cat.setXXX();;   
  
  
daoimpl.addCat(cat);;   
  
  
daoimpl.addMate(cat, mate);; 
 
 

The cat is persistent before other persistent operations can be performed on the cat. Therefore, programmers at the business layer must be clear about the state of the cat object, whether it is the first or the third. If it is the first type, you must first save and then addmate; if it is the third type, you can directly addmate.

But the most critical thing is that if there are many layers of software, the programmer at the business layer may also get this cat object from the upper web application layer, he does not know whether the cat is Vo, whether it has not been persisted, or whether it has been persisted, so he has no way to write a program.

Therefore, such daoimpl is obviously problematic. It will cause many programming traps for programmers at the business layer, the programmer at the business layer must have a profound understanding of the status management of the Po object for each DAO he calls, and must have a profound understanding of the exact status of his PO object at any time, in order to ensure the correctness of programming, this is obviously not possible, but with saveorupdate, these problems can be solved.

Now you need to modify the addmate method:

Java code:

 
 

  
  
public void addMate(Cat cat, Mate mate); {     
  
  
     Session session = ...;     
  
  
     Transacton tx = ...;     
  
  
     session.saveOrUpdate(cat);;     
  
  
     cat.addMate(mate);;     
  
  
     tx.commit();;     
  
  
     session.close();;     
  
  
};     
  
  
public void addMate(Cat cat, Mate mate);   
  
  
{     Session session = ...;     Transacton tx = ...;       
  
  
session.saveOrUpdate(cat);;     cat.addMate(mate);;       
  
  
tx.commit();;     session.close();; }; 
 
 

As shown above, if the programmer at the business layer transmits a persistent Po object, Hibernate updates the cat object (assuming that the programmer at the business layer modifies the cat attribute outside the session ), if a new object is input, save the Po object to the database.

BTW: whether hibernate updates the cat object or saves the cat object depends on the setting of unsave-value.

In this way, programmers at the business layer do not have to worry about the Po status. For them, whether cat is a new object, it is just a vo; or the Po objects queried from the database are all directly addmate and OK:

Java code:

 
 

  
  
daoimple.addMate(cat, mate);;     
  
  
daoimple.addMate(cat, mate);; 
 
 

This is the role of hibernate saveorupdate.