Update and SaveorUpdate Detailed
Author: robbin (MSN: robbin_fan AT hotmail DOT com) in Hibernate, the core concept is to state PO management. One PO has three states:
1. VO that is not persisted
At this time, a memory object Vo is managed by the JVM.
2, the PO that has been persisted, and within the session life cycle
At this point, the database data is mapped, and the life cycle is managed by the database.
3, I have been persisted, but now and session have detached, run in VO's identity
The PO of this and session already detached can also enter another session, continuing to perform PO status management, and it becomes the second state of PO. This type of PO is actually maintained by SESSION.
In the traditional JDO1.x, the PO only has two states. Once a PO is separated from PM, it is lost, it is no longer associated with the database data, and becomes a pure memory Vo, which even enters a new PM, Can't restore its state.
Hibernate is in that, after a PO is separated from session, it can also keep a state. After entering a new session, restore status management capabilities, but at this time, the status management needs to use session.Update or session.saveorupdate, this is "Requires a Slightly Different Programming Model" mentioned in Hibernate Reference
Now officially enter this topic:
Simply, Update and SaveorUpdate are used to manage PO across the session.
Suppose your PO does not need to cross the session, then you don't need to use, for example, you open a session, do it, then turn it off, then this PO you will not use it, then you don't need to use Update.
So let's take a look:
Foo foo = sess.load (foo.class, id);
Foo.setxxx (xxx);
sess.flush ();
sess.commit ();
The operation of the PO object FOO is completed within a session life cycle, so there is no need to explicitly perform SESS.UPDATE (FOO) operations. Hibernate automatically monitors the Foo object has been modified, so send an Update SQL to the database. Of course, if you have to add sess.update (foo), it will not be wrong, but there is no need to do this.
And the meaning of session is that this PO object has been used as a VO after session, and then you have modified its properties outside, then you want to open a session, modify the property of VO Save to the database, then you need Update.
// 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 Matecat and Mate objects are made in the first session, after the first session is closed, they become the third state of PO, and the session has detached PO, At this point their status information is still retained. When they entered the second session, they can be updated immediately. However, due to the modification of CAT: Cat.SetMate (PotentialMate); is outside the session, Hibernate can't know that the Cat object has been changed, the second session does not know this modification, so it must explicitly Call SecondSession.Update (CAT); notify hibernate, the Cat object has been modified, you must send Update's SQL.
So the role of Update is here, it will only be used to write when a PO object is synchronized across the session. And a PO object does not need to write Update when it does not need to manage state management across the session.
Talk again with Saveorupdate:
The difference between SaveorUpdate and Update is what policy takes to PO in PO state management across session.
For example, when you write a DaoIMPL, let the CAT object add a MATE, as follows:
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's operation in Dao, so that the programmer of the business layer and the web layer does not need to know Hibernate, call the DAO.
At this time, the problem is coming: The above code is running correctly, that is, the method calling the parameter Cat object must be a PO that has been persisted, that is, it should first query from the database, then Can use this way. But the programmer of the business layer obviously doesn't know this internal mystery. If his business is now adding a cat, then add its MATE, he obviously calls, New a cat object, then addmate:
Cat cat = new cat ();
Cat.setxxx ();
DaoImpl.addmate (CAT, MATE);
But please note, this cat object is just a Vo, it is not persisted, it is not PO, it is not eligible to call the Addmate method, so call the addmate method to send Update SQL to the database, this CAT object must First by SAVE to the database, you have the qualifications for addMate after you really become a PO.
You have to do this:
Cat cat = new cat ();
Cat.setxxx ();
DaoImpl.addcat (cat);
DaoImpl.addmate (CAT, MATE);
Popularize CAT first before you can do other persistent operations for CAT. Therefore, the programmer that requires the business layer must clear what state is in the CAT object, and the first is the first, or the third. If it is the first, you must first save, then addMate; if it is a third, you will directly addMate.
But the most deadly is that if the entire software is slid, the programmer of the business layer, he got this CAT object, it might be the CAT passing through the upper web application layer. He doesn't know that this CAT is VO, not lasting. After it is, it has been persisted, then he has no way to write the program at all. So this DaoIMPL is obviously problematic. It will cause a lot of programmed traps on the business layer, and the programmer of the business layer must be profoundly understanding what the DAO he calls is to manage the PO object. You must understand what the PO object is in any exact state at any time, in order to ensure the correctness of the programming, obviously don't do it, but there is SaveorupDate, these questions are solved.
Now you need to modify the Addmate method:
Public void addmate (Cat Cat, Mate Mate) {
Session session = ...
Transacton TX = ...
session.saveorupdate (cat);
Cat.Addmate (MATE);
TX.comMit ();
session.close ();
}
As mentioned above, if the programmer of the business layer is coming in, it is a persisted PO object, then Hibernate updates the Cat object (assuming that the programmer of the business layer modifies the CAT attribute outside the session), if it is passed The new New's object, then to the database Save this PO object.
BTW: Hibernate At this time, the CAT object is taken, or the Save Cat object depends on the setting of Unsave-Value.
In this way, the programmer of the business layer does not have to worry about the status of PO. For them, regardless of CAT is the object coming out, it is just a VO; or the PO object from the database is also good, all It is OK that is directly addmate:
DaoImple.Addmate (CAT, MATE);
This is the role of saveorupdate.
