(update() aktualisiert, wenn kein Primärschlüssel vorhanden ist, wird ein Fehler gemeldet.
saveOrUpdate() speichert oder aktualisiert, führt Einfügung ohne Primärschlüssel durch.
Update: Es handelt sich um einen Update-Vorgang für transiente (transiente) oder einfach losgelöste (distached) Objekte. Der Update-Vorgang für transiente Objekte hat in der Regel keine Auswirkung. Bei losgelösten Objekten wird ein Synchronisationsvorgang durchgeführt, d. h. die Daten der Datenbank ändern sich. Und der Objektstatus wird auch zu einem verwalteten Objekt
SaveOrUpdate: Es funktioniert auch bei vorübergehenden oder getrennten Vorgängen. Ob eingefügt oder aktualisiert werden soll, muss anhand einiger spezifischer Bedingungen analysiert werden, die in der ID angegeben sind. Ich persönlich denke jedoch, dass es besser ist, saveOrUpdate zu vermeiden und einfach save direkt zu verwenden, wenn es offensichtlich ist, dass nur der Einfügevorgang ausgeführt wird.
Beginnen wir mit einigen Konzepten:
Das Kernkonzept von Hibernate ist die Zustandsverwaltung von PO. Eine Bestellung hat drei Zustände:
1. VO, die nicht beibehalten wird
Zu diesem Zeitpunkt handelt es sich um ein Speicherobjekt-VO, und der Lebenszyklus wird von der JVM verwaltet.
2. Die Bestellung wurde beibehalten und die Datenbankdaten werden zu diesem Zeitpunkt während des Sitzungslebenszyklus zugeordnet, und die Datenbank verwaltet den Lebenszyklus.
3. Es wurde beibehalten, aber jetzt wurde es von der Sitzung getrennt. Wenn Sie diese von der Sitzung getrennte Bestellung als VO ausführen, können Sie zu diesem Zeitpunkt auch eine andere Sitzung eingeben und den PO-Status weiterhin verwalten , es wird ein PO. Diese Art von PO kreuzt sich tatsächlich
Die Sitzung führt die Zustandswartung durch.
Im herkömmlichen JDO1.x hat PO nur die ersten beiden Zustände. Sobald ein PO vom PM getrennt wird, verliert er seinen Zustand und ist nicht mehr mit Datenbankdaten verknüpft. Er wird zu einem reinen Speicher-VO.
Selbst wenn Sie eine neue PM hinzufügen, kann deren Status nicht wiederhergestellt werden.
Die Stärke von Hibernate besteht darin, dass ein PO den Status weiterhin aufrechterhalten kann. Nach dem Eintritt in eine neue Sitzung ist die Statusverwaltungsfähigkeit jedoch wiederhergestellt
Sie müssen session.update oder session.saveOrUpdate verwenden, was in der Hibernate-Referenz unter „erfordert eine etwas andere Programmierung“ erwähnt wird
Modell"
Betreten Sie dieses Thema nun offiziell:
Einfach ausgedrückt werden update und saveOrUpdate verwendet, um den Status sitzungsübergreifender POs zu verwalten.
Unter der Annahme, dass Ihr PO nicht sitzungsübergreifend sein muss, besteht keine Notwendigkeit, ihn zu verwenden. Wenn Sie beispielsweise eine Sitzung öffnen, den PO ausführen und ihn dann schließen, wird dieser PO nicht erneut verwendet.
Dann ist die Verwendung von Update nicht erforderlich.
Schauen wir uns also das obige Beispiel an:
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);;
Die Vorgänge des PO-Objekts foo werden alle innerhalb eines Sitzungslebenszyklus abgeschlossen, sodass keine Notwendigkeit besteht, Vorgänge wie sess.update(foo) explizit auszuführen. Der Ruhezustand erkennt automatisch, dass das foo-Objekt vorhanden ist
wurde geändert, sodass ein Update-SQL an die Datenbank gesendet wird. Natürlich ist es nicht falsch, wenn Sie darauf bestehen, sess.update(foo) hinzuzufügen, aber es besteht keine Notwendigkeit, dies zu tun.
Sitzungsübergreifend bedeutet, dass Sie dieses PO-Objekt nach dem Schließen der Sitzung weiterhin als VO verwenden. Später ändern Sie seine Eigenschaften außerhalb der Sitzung und möchten es dann erneut öffnen.
Öffnen Sie eine Sitzung und speichern Sie die VO-Attributänderungen in der Datenbank. Anschließend müssen Sie „Update“ verwenden.
Java-Code
// in der ersten Sitzung
Cat cat = (Cat); firstSession.load(Cat.class, catId);;
Cat PotentialMate = new Cat();;
firstSession.save(potentialMate);;
// in einer höheren Ebene der Anwendung
cat.setMate(potentialMate);;
// später, in einer neuen Sitzung
secondSession.update(cat);; // cat aktualisieren
secondSession.update(mate);; // mate aktualisieren
// in der ersten Sitzung Cat cat = (Cat); firstSession.load(Cat.class, catId);; Cat potentialMate = new Cat();;
firstSession.save(potentialMate);; // in einer höheren Ebene der Anwendung cat.setMate(potentialMate);;
neue Sitzung secondSession.update(cat);; // update cat secondSession.update(mate); // update mate
Die Katzen- und Mate-Objekte werden in der ersten Sitzung abgerufen, nachdem die erste Sitzung geschlossen wurde, und werden zu dem PO, den die Sitzung zu diesem Zeitpunkt getrennt hat
Ihre Statusinformationen bleiben weiterhin erhalten. Wenn sie die zweite Sitzung betreten, können sie den Status sofort aktualisieren. Aber aufgrund der Änderungsoperation an cat: cat.setMate
(potentialMate); wird außerhalb der Sitzung ausgeführt. Der Ruhezustand kann nicht wissen, dass das Cat-Objekt geändert wurde, daher muss es explizit sein.
Rufen Sie secondSession.update(cat) auf, um Hibernate darüber zu informieren, dass das Cat-Objekt geändert wurde und Sie die Update-SQL senden müssen.
Dies ist also die Rolle der Aktualisierung. Sie wird nur geschrieben, wenn ein PO-Objekt seinen Status sitzungsübergreifend synchronisiert. Wenn ein PO-Objekt nicht sitzungsübergreifend verarbeitet werden muss,
Bei der Statusverwaltung ist es nicht erforderlich, Aktualisierungen zu schreiben.
Lassen Sie uns über die Verwendung von saveOrUpdate sprechen:
Der Unterschied zwischen saveOrUpdate und update liegt in der Strategie, die Hibernate für PO bei der sitzungsübergreifenden PO-Statusverwaltung anwendet.
Wenn Sie beispielsweise ein DAOImpl schreiben, fügen Sie dem Katzenobjekt ein Mate hinzu, wie unten definiert:
Java-Code
public void addMate(Cat cat, Mate mate);
Sitzungssitzung = ...;
Transacton tx = ...;
session.update(cat);;
cat.addMate(mate);;
tx.commit();;
session.close();;
};
public void addMate(Cat cat, Mate mate); { Session session = ...; Transacton tx = ...;
cat.addMate(mate);; tx.commit();; session.close();;
Offensichtlich müssen Sie Hibernate-Vorgänge in DAO kapseln, damit Business-Layer-Programmierer und Web-Layer-Programmierer Hibernate nicht kennen und DAO direkt aufrufen müssen.
An diesem Punkt tritt das Problem auf: Es gibt eine notwendige Voraussetzung für die korrekte Ausführung des obigen Codes, d
Fragen Sie es zuerst aus der Datenbank ab und verwenden Sie es dann so. Aber Programmierer auf der Geschäftsebene kennen dieses interne Geheimnis offensichtlich nicht, wenn es seine Aufgabe ist, ab und zu eine Katze hinzuzufügen
Sein Kumpel, er wird es offensichtlich so nennen, ein neues Katzenobjekt kommt heraus und dann addMate:
Java-Code
Katze cat = new Cat();;
cat.setXXX();;
daoimpl.addMate(cat,mate);;
Katze cat = new Cat();; cat.setXXX();; daoimpl.addMate(cat,mate);;
Bitte beachten Sie jedoch, dass dieses Katzenobjekt nur ein VO ist, nicht beibehalten wurde, kein PO ist und nicht zum Aufrufen der addMate-Methode qualifiziert ist, sodass der Aufruf der addMate-Methode nicht tatsächlich ausgeführt wird
Um Update-SQL in der Datenbank zu senden, muss das Cat-Objekt zuerst in der Datenbank gespeichert werden. Erst nachdem es wirklich zu einem PO wird, kann es für addMate qualifiziert werden.
Du musst es so machen:
Java-Code
Katze cat = new Cat();;
cat.setXXX();;
daoimpl.addCat(cat);;
daoimpl.addMate(cat, mate);;
Katze cat = new Cat();; cat.setXXX();; daoimpl.addCat(cat);;
Behalten Sie zuerst cat bei und führen Sie dann andere Persistenzvorgänge für cat durch. Daher müssen Programmierer auf der Geschäftsebene wissen, in welchem Zustand sich das Katzenobjekt befindet, ob es das erste oder das dritte ist.
Wenn es sich um den ersten Typ handelt, müssen Sie zuerst speichern und dann addMate verwenden. Wenn es sich um den dritten Typ handelt, müssen Sie einfach addMate direkt hinzufügen.
Das Schlimmste ist jedoch, dass, wenn die gesamte Software viele Schichten hat, das Katzenobjekt, das der Programmierer der Geschäftsschicht erhält, möglicherweise die Katze ist, die von der oberen Webanwendungsschicht übergeben wird, und er selbst weiß das nicht.
Unabhängig davon, ob cat VO ist, nicht beibehalten wurde oder beibehalten wurde, hat er überhaupt keine Möglichkeit, ein Programm zu schreiben.
Ein solches DAOImpl ist also offensichtlich problematisch. Es führt zu vielen Programmierfallen für Business-Layer-Programmierer. Business-Layer-Programmierer müssen über ein tiefes Verständnis für jedes von ihnen aufgerufene DAO-Paar verfügen.
Welche Art von Zustandsverwaltung durchgeführt wird, muss jederzeit ein tiefes Verständnis des genauen Zustands seines PO-Objekts haben, um die Korrektheit der Programmierung sicherzustellen, aber mit
Mit saveOrUpdate lassen sich diese Probleme leicht lösen.
Jetzt müssen Sie die addMate-Methode ändern:
Java-Code
public void addMate(Cat cat, Mate mate);
Sitzungssitzung = ...;
Transacton tx = ...;
session.saveOrUpdate(cat);;
cat.addMate(mate);;
tx.commit();;
session.close();;
};
public void addMate(Cat cat, Mate mate); { Session session = ...; Transacton tx = ...;
(cat);; cat.addMate(mate);; tx.commit();;
Wenn der Business-Layer-Programmierer wie oben ein persistentes PO-Objekt übergibt, aktualisiert Hibernate das Cat-Objekt (vorausgesetzt, der Business-Layer-Programmierer hat es außerhalb der Sitzung geändert).
cat-Attribut), wenn es sich bei dem übergebenen Objekt um ein neues Objekt handelt, speichern Sie das PO-Objekt in der Datenbank.
Übrigens: Ob Hibernate das Cat-Objekt zu diesem Zeitpunkt aktualisiert oder speichert, hängt von der Einstellung von unsave-value ab.
Auf diese Weise müssen sich Programmierer auf der Business-Ebene keine Gedanken mehr über den Status der PO machen. Für sie spielt es keine Rolle, ob cat ein neues Objekt, nur ein VO, ist oder aus der Datenbank abgefragt wird.
Unabhängig von den PO-Objekten können alle direkt zu addMate hinzugefügt werden:
Java-Code
daoimple.addMate(cat, mate);;
daoimple.addMate(cat, mate);;
Dies ist, was saveOrUpdate tut.
Dieser Artikel stammt aus dem CSDN-Blog. Bitte geben Sie beim Nachdruck die Quelle an: http://blog.csdn.net/zhrl0000/archive/2009/12/17/5027965.aspx
-