(update() updates, if there is no primary key, an error will be reported.
saveOrUpdate() saves or updates, performs insert without primary key.
Update: It is an update operation for transient (transient) or just detached (detached). The update operation for transient objects usually has no effect. For detached objects, a synchronization operation is performed, that is, the data of the database changes. And the object state also becomes a managed object
SaveOrUpdate: It also operates on transient or detached operations. As for whether to insert or update, it must be analyzed according to some specific conditions specified in the id. However, I personally think that when it is obvious that only the insertion operation will occur, it is better to avoid using saveOrUpdate and just use save directly)
Let’s start with some concepts:
In Hibernate, the core concept is the state management of PO. A PO has three states:
1. VO that is not persisted
At this time, it is a memory object VO, and the life cycle is managed by the JVM.
2. The PO has been persisted, and the database data is mapped at this time during the Session life cycle, and the database manages the life cycle.
3. It has been persisted, but now it has been detached from the Session. If you run this PO that has been detached from the Session as a VO, you can also enter another Session and continue to manage the PO state. At this time, it becomes a PO. The second state. This kind of PO actually crosses
Session performs state maintenance.
In traditional JDO1.x, PO only has the first two states. Once a PO is separated from the PM, it loses its state and is no longer associated with database data. It becomes a pure memory VO.
Even if you add a new PM, its status cannot be restored.
The strength of Hibernate is that after a PO leaves the Session, it can still maintain the state. After entering a new Session, the state management capability is restored. But at this time, the state management
You need to use session.update or session.saveOrUpdate, which is what the Hibernate Reference mentioned in "requires a slightly different programming
model”
Now officially enter this topic:
Simply put, update and saveOrUpdate are used to manage the status of cross-session POs.
Assuming that your PO does not need to cross Sessions, then there is no need to use it. For example, if you open a Session, operate the PO, and then close it, you will not use this PO again.
Then there is no need to use update.
So let's look at the above 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 of PO object foo are all completed within a Session life cycle, so there is no need to explicitly perform operations such as sess.update(foo). Hibernate will automatically detect that the foo object has
has been modified, so an update sql is sent to the database. Of course, it's not wrong if you insist on adding sess.update(foo), but there is no need to do so.
Cross-Session means that after the Session is closed, you still use this PO object as a VO. Later, you modify its properties outside the Session, and then you want to open it again.
Open a Session and save the VO attribute modifications to the database, then you need to use 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, they become the third state of the PO, and the PO that the Session has detached. At this time, they
Their status information is still retained. When they enter the second session, they can immediately update the status. But due to the modification operation on cat: cat.setMate
(potentialMate); is performed outside the Session. Hibernate cannot know that the cat object has been modified. The second Session does not know this modification, so it must be explicit.
Call secondSession.update(cat); to notify Hibernate that the cat object has been modified and you must send the update sql.
So this is the role of update. It will only be written when a PO object is synchronizing its status across Sessions. When a PO object does not need to be processed across Sessions,
When performing state management, there is no need to write updates.
Let’s talk about the use of saveOrUpdate:
The difference between saveOrUpdate and update lies in the strategy Hibernate adopts 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 business layer programmers and Web layer programmers do not need to know Hibernate and directly call DAO.
At this point the problem arises: there is a necessary prerequisite for the above code to run correctly, that is, the method call parameter cat object must be a PO that has been persisted, that is, it should
First query it from the database and then use it like this. But programmers at the business layer obviously don’t know this internal mystery. If his business is to add a cat now and then add
Its mate, he will obviously call it like this, a new cat object comes out, and then addMate:
Java code
Cat cat = new Cat();;
cat.setXXX();;
daoimpl.addMate(cat,mate);;
Cat cat = new Cat();; cat.setXXX();; daoimpl.addMate(cat,mate);;
But please note that this cat object is just a VO, it has not been persisted, it is not a PO, and it is not qualified to call the addMate method, so calling the addMate method will not actually go to
To send update sql in the database, the cat object must be saved to the database first. Only after it truly becomes a PO can it be qualified for addMate.
You have to do it like this:
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);;
Persist cat first, and then perform other persistence operations on cat. Therefore, programmers at the business layer must know what state the cat object is in, whether it is the first or the third.
If it is the first type, you need to save first and then addMate; if it is the third type, just addMate directly.
But the most fatal thing is that if the entire software has many layers, the cat object that the business layer programmer gets may be the cat passed from the upper web application layer, and he himself does not know this.
Whether cat is VO, has not been persisted, or has been persisted, then he has no way to write a program at all.
So such a DAOImpl is obviously problematic. It will cause many programming traps for business layer programmers. Business layer programmers must have a deep understanding of each DAO pair PO pair they call.
What kind of state management is carried out, you must have a deep understanding of the exact state of his PO object at any time to ensure the correctness of programming. Obviously this is impossible, but with
saveOrUpdate, these problems are easily 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 above, if the business layer programmer passes in a PO object that has been persisted, then Hibernate will update the cat object (assuming that the business layer programmer has modified it outside the Session)
cat attribute), if what is passed in is a new object, then save the PO object to the database.
BTW: Whether Hibernate updates the cat object or saves the cat object at this time depends on the setting of unsave-value.
In this way, programmers at the business layer no longer have to worry about the status of the PO. For them, it doesn't matter whether cat is a new object, just a VO, or it is queried from the database.
Regardless of the PO objects, all of them can be added directly to addMate:
Java code
daoimple.addMate(cat, mate);;
daoimple.addMate(cat, mate);;
This is what saveOrUpdate does.
This article comes from the CSDN blog. Please indicate the source when reprinting: http://blog.csdn.net/zhrl0000/archive/2009/12/17/5027965.aspx
-