JPA EntityManager: Warum Gebrauch bestehen () über merge ()?

Question

EntityManager.merge() können neue Objekte einfügen und bestehende aktualisieren.

Warum sollte man wollen persist() verwenden (die nur neue Objekte erstellen können)?

Answer 1

In beiden Fällen wird ein Unternehmen zu einem PersistenceContext hinzufügen, ist der Unterschied in dem, was Sie danach mit dem Unternehmen zu tun.

Persist eine Entitätsinstanz nimmt, fügt sie dem Kontext und macht diese Instanz verwaltet (dh zukünftige Aktualisierungen der Einheit verfolgt werden).

Merge erstellt eine neue Instanz der Einheit, kopiert den Zustand von der mitgelieferten Einheit und macht die neue Kopie verwaltet. Die Instanz, die Sie passieren in nicht verwaltet werden (alle Änderungen werden nicht Teil der Transaktion sein zu lassen - es sei denn, Sie wieder fusioniert Anruf).

Vielleicht ein Codebeispiel helfen.

MyEntity e = new MyEntity();

// scenario 1
// tran starts
em.persist(e); 
e.setSomeField(someValue); 
// tran ends, and the row for someField is updated in the database

// scenario 2
// tran starts
e = new MyEntity();
em.merge(e);
e.setSomeField(anotherValue); 
// tran ends but the row for someField is not updated in the database
// (you made the changes *after* merging)

// scenario 3
// tran starts
e = new MyEntity();
MyEntity e2 = em.merge(e);
e2.setSomeField(anotherValue); 
// tran ends and the row for someField is updated
// (the changes were made to e2, not e)

Szenario 1 und 3 sind etwa gleich, aber es gibt einige Situationen, in denen man sich wünschen kann Szenario 2 verwenden,

Answer 2

Persist

und merge sind für zwei unterschiedliche Zwecke (sie überhaupt keine Alternativen sind).

(herausgegeben von Unterschieden Informationen zu erweitern)

bestehen:

• Fügen Sie ein neues Register zur Datenbank
• Schließen Sie das Objekt an die Instanz-Manager.

merge:

• Finden Sie ein befestigtes Objekt mit derselben ID und aktualisieren Sie es.
• Falls vorhanden Update und gibt das bereits angebrachte Objekt.
• Wenn nicht existiert das neue Register in die Datenbank eingefügt werden.

persistieren () Effizienz:

• Es könnte sein, effiziente für ein neues Register mit einer Datenbank als merge Einfügen ().
• Es ist nicht das ursprüngliche Objekt kopiert.

persistieren () Semantik:

• Es stellt sicher, dass Sie einfügen und nicht versehentlich zu aktualisieren.

Beispiel:

{
    AnyEntity newEntity;
    AnyEntity nonAttachedEntity;
    AnyEntity attachedEntity;

    // Create a new entity and persist it        
    newEntity = new AnyEntity();
    em.persist(newEntity);

    // Save 1 to the database at next flush
    newEntity.setValue(1);

    // Create a new entity with the same Id than the persisted one.
    AnyEntity nonAttachedEntity = new AnyEntity();
    nonAttachedEntity.setId(newEntity.getId());

    // Save 2 to the database at next flush instead of 1!!!
    nonAttachedEntity.setValue(2);
    attachedEntity = em.merge(nonAttachedEntity);

    // This condition returns true
    // merge has found the already attached object (newEntity) and returns it.
    if(attachedEntity==newEntity) {
            System.out.print("They are the same object!");
    }

    // Set 3 to value
    attachedEntity.setValue(3);
    // Really, now both are the same object. Prints 3
    System.out.println(newEntity.getValue());

    // Modify the un attached object has no effect to the entity manager
    // nor to the other objects
    nonAttachedEntity.setValue(42);
}

Auf diese Weise gibt es nur 1 hinzugefügte Objekt für jedes Register in dem Entity-Manager.

merge () für eine Entität mit einer ID ist so etwas wie:

AnyEntity myMerge(AnyEntity entityToSave) {
    AnyEntity attached = em.find(AnyEntity.class, entityToSave.getId());
    if(attached==null) {
            attached = new AnyEntity();
            em.persist(attached);
    }
    BeanUtils.copyProperties(attached, entityToSave);

    return attached;
}

Obwohl verbunden, wenn zu MySQL fusionieren () könnte so effizient sein wie persistieren () einen Anruf mit mit ON DUPLICATE KEY UPDATE Option INSERT, JPA eine sehr hohe Level-Programmierung und man kann nicht davon ausgehen, das wird das sein, Fall überall.

Answer 3

Wenn Sie den zugeordneten Generator verwenden, mit persistieren statt fusionieren kann eine redundante SQL verursachen Aussage daher die Leistung beeinträchtigt.

Auch für verwaltete Einheiten Aufruf verschmelzen auch ein Fehler, da verwaltete Einheiten sind automatisch verwaltet von Hibernate und ihr Zustand wird mit dem Datenbankeintrag durch die auf die Persistence Context Spülung.

Um zu verstehen, wie das alles funktioniert, sollten Sie zuerst wissen, dass Hibernate die Entwickler Einstellung von SQL-Anweisungen Einheit Zustandsübergänge .

Sobald ein Unternehmen aktiv von Hibernate verwaltet wird, werden alle Änderungen werden automatisch in der Datenbank gespeichert werden.

Ruhezustand überwacht derzeit Entitäten angebracht. Aber für ein Unternehmen verwaltet werden, muss sie in der richtigen Einheit Zustand sein.

Zuerst müssen wir alle Objektzustände definieren:

• Neu (Transient)

  Ein neu erstelltes Objekt, das nicht immer mit einer Hibernate Session zugeordnet wurde (a.k.a Persistence Context) und ist nicht auf eine Datenbanktabelle Zeile abgebildet wird als in dem neuen (Transient) Zustand sein.

  Um sich fort, müssen wir entweder explizit die EntityManager#persist Methode aufrufen oder die Verwendung des transitiven Persistenzmechanismus machen.

• Persistent (verwaltet)

  Eine hartnäckige Einheit wurde mit einer Datenbanktabelle Zeile zuzugeordnet und es durch die aktuellen Lauf Persistence Context verwaltet werden wird. Jede Änderung dieser juristischen Person gemacht wird in der Datenbank erfasst und weitergegeben werden (während der Session flush-Zeit). Mit Hibernate, wir müssen nicht mehr INSERT / UPDATE / DELETE-Anweisungen ausführen. Hibernate verwendet einen Transaktionsschreib hinter Arbeitsstil und Änderungen sind im allerletzten Moment verantwortlich synchronisiert, während der aktuelle Session flush-Zeit.

• Freistehendes

  Sobald der aktuelle läuft Persistence Context geschlossen wird alle zuvor verwalteten Einheiten lösen sich. Aufeinander folgende Änderungen nicht mehr verfolgt werden und keine automatische Datenbanksynchronisation passieren wird.

  Um eine freistehende Einheit in einen aktiven Hibernate Session zuordnen, können Sie eine der folgenden Möglichkeiten wählen:

  • Erneutes Anbringen

    Ruhezustand (aber nicht JPA 2.1) unterstützt durch die Session # Update-Methode reattaching. Eine Hibernate Session kann nur assoziieren ein Entity-Objekt für eine bestimmte Datenbankzeile. Dies ist, weil die Persistenzkontext wirkt als in-Speicher-Cache (Cache der ersten Ebene) und nur ein Wert (Einheit) zu einem gegebenen Schlüssel zugeordnet ist (Entitätstyp und Datenbank identifier). Ein Unternehmen kann nur wiederverwendet werden, wenn es kein anderes JVM-Objekt ist (die gleiche Datenbank Zeile entspricht) bereits zugeordnet auf die aktuelle Hibernate Session.

  • Merging

  Die Zusammenführung wird die freistehenden Entitätsstatus (Quelle) zu einer verwalteten Entitätsinstanz (Ziel) kopieren. Wenn das Verschmelzen Entität keine Entsprechung in der aktuellen Sitzung hat, wird man aus der Datenbank abgerufen werden. Die freistehende Objektinstanz wird weiterhin losgelöst auch nach dem Druckvorgang bleiben.

• entfernt

  Obwohl JPA Anforderungen, die Einheiten nur verwaltet werden, dürfen entfernt werden, kann Hibernate auch frei stehende Einheiten löschen (aber nur durch eine Session # Methodenaufruf löschen). Eine Entität entfernt ist nur für d geplanteletion und die eigentliche Datenbank DELETE-Anweisung wird während der Session flush-Zeit.

ausgeführt werden

Um die JPA Zustandsübergänge besser zu verstehen, können Sie das folgende Diagramm visualisieren:

Oder wenn Sie die Hibernate spezifische API verwenden:

Answer 4

Ich habe bemerkt, dass, wenn ich em.merge verwendet, die ich für jeden SELECT eine INSERT Erklärung bekommen, auch wenn es kein Feld war, die JPA für mich Erzeugung - das Primärschlüsselfeld war eine UUID, die ich mir gesetzt. Ich wechselte em.persist(myEntityObject) und bekam nur INSERT Aussagen dann.

Answer 5

Die JPA-Spezifikation sagt folgendes über persist().

  

Wenn X ist ein frei stehendes Objekt, das EntityExistsException geworfen werden, wenn die bestehen bleiben   Operation aufgerufen wird, oder die EntityExistsException oder eine andere PersistenceException kann bei Flush oder begehen Zeit geworfen werden.

So persist() Verwendung geeignet wäre, wenn das Objekt sollte nicht ein freistehendes Objekt sein. Sie könnten es vorziehen, den Code zu haben, die PersistenceException zu werfen, so dass es schnell ausfällt.

Obwohl die Spezifikation unklar ist, persist() könnte gesetzt der @GeneratedValue @Id für ein Objekt. merge() jedoch muss ein Objekt mit dem @Id bereits erzeugt.

Answer 6

Es gibt einige weitere Unterschiede zwischen merge und persist (ich aufzählen wieder die bereits hier gepostet):

D1. merge macht nicht die übergebene Einheit verwaltet, sondern gibt eine andere Instanz, die verwaltet wird. persist auf der anderen Seite wird die übergebene Einheit machen verwaltet:

//MERGE: passedEntity remains unmanaged, but newEntity will be managed
Entity newEntity = em.merge(passedEntity);

//PERSIST: passedEntity will be managed after this
em.persist(passedEntity);

D2. Wenn Sie ein Objekt entfernen, und dann entscheiden, um die Einheit bestehen bleiben zurück, können Sie das tun, nur mit persistieren (), weil merge wird ein IllegalArgumentException werfen.

D3. Wenn entschieden ist darauf zu achten manuell Ihre IDs (z durch UUIDs verwenden), dann ein merge Betrieb löst nachfolgende SELECT Abfragen, um mit dieser ID für vorhandene Einrichtungen zu suchen, während persist möglicherweise nicht diese Abfragen benötigt.

D4. Es gibt Fälle, wenn Sie einfach den Code nicht vertrauen, dass Ihr Code aufruft, und um sicher zu stellen, dass keine Daten aktualisiert werden, sondern eingeführt wird, Sie persist verwenden müssen.

Answer 7

Einige weitere Details zu verschmelzen, die Sie über die Verwendung helfen verschmelzen bestehen:

  

eine verwaltete Instanz andere als die ursprüngliche Einheit zurückkehrend ist ein wichtiger Teil des Merge   Prozess. Wenn ein Unternehmen beispielsweise mit der gleichen Kennung existiert bereits in der Persistenzkontext, die   Anbieter wird seinen Zustand mit dem Zustand des Unternehmens überschreiben, die zusammengeführt wird, aber das verwaltete   Version, die bereits vorhanden ist an den Client zurückgegeben werden, so dass es verwendet werden kann. Wenn der Anbieter nicht tat   Aktualisieren Sie die Mitarbeiter Instanz im Persistenzkontext, sind die Verweise auf diese Instanz wird sich   unvereinbar mit dem neuen Staat in verschmolzen werden.

     

Wenn merge () auf eine neue Einheit aufgerufen wird, verhält es sich ähnlich wie bei der persistieren () Betrieb. Es fügt hinzu   das Unternehmen auf die Persistenzkontext, sondern die ursprüngliche Entitätsinstanz hinzuzufügen, erstellt es einen neuen   Kopieren und verwaltet diese Instanz statt. Die Kopie, die durch das Zusammenführen () Befehl erzeugt wird, beibehalten   als ob die persistieren () -Methode für sie aufgerufen wurden.

     

In Gegenwart von Beziehungen, die merge () Operation versucht, die verwaltete Einheit zu aktualisieren   verwalteten Versionen der Einheiten durch die freistehende Einheit verwiesen zu zeigen. Wenn das Unternehmen hat eine   Beziehung zu einem Objekt, das keine persistente Identität hat, ist das Ergebnis der Mischoperation   nicht definiert. Einige Anbieter erlauben könnten, die verwaltete Kopie an das nicht-persistente Objekt zu zeigen,   während andere vielleicht sofort eine Ausnahme werfen. Die merge () -Operation kann optional sein,   in diesen Fällen kaskadiert auftretende eine Ausnahme von zu verhindern. Wir decken Kaskadierung des merge ()   Betrieb später in diesem Abschnitt. Wenn ein Unternehmen zu einer entfernten Einheit fusionierten Punkte sein, ein   Illegal Ausnahme wird geworfen werden.

     

Lazy-Laden Beziehungen sind ein Sonderfall in dem Druckvorgang. Wenn ein lazy-Laden   Beziehung wurde nicht auf eine Einheit ausgelöst, bevor sie abgelöst wurde, wird diese Beziehung sein   ignoriert, wenn das Unternehmen verschmolzen wird. Wenn die Beziehung ausgelöst wurde, während verwaltet und dann auf null gesetzt, während die Einheit abgelöst wurde, wird die verwaltete Version des Unternehmens ebenfalls die Beziehung während der Zusammenführung gelöscht hat. "

"Die Beherrschung der Java ™ Persistence API Pro JPA 2" von Mike Keith und Merrick Schnicariol

Alle oben genannten Informationen wurden von genommen. Kapitel 6. Abschnitt Ablösung und Zusammenführung. Dieses Buch ist eigentlich ein zweites Buch zu JPA von Autoren gewidmet. Dieses neue Buch hat viele neue Informationen dann frühere. Ich recommed wirklich dieses Buch für diejenigen zu lesen, die sich ernsthaft mit JPA beteiligt sein werden. Es tut mir leid für anonimously meine erste Antwort veröffentlichen.

Answer 8

Ich war immer Lazy Loading Ausnahmen auf meiner Einheit, weil ich eine faule geladene Sammlung zuzugreifen versuche, die in der Sitzung war.

Was ich in einem separaten Antrag war würde, die Einheit von Sitzung abrufen und dann versuchen, eine Sammlung in meiner jsp Seite zuzugreifen, die problematisch war.

Um dies zu erleichtern, habe ich die gleiche Einheit in meinen Controller aktualisiert und übergeben es an meine jsp, obwohl ich denke, wenn ich in der Sitzung erneut gespeichert, dass es auch wenn SessionScope zugänglich sein wird und kein LazyLoadingException werfen, die eine Modifikation des Beispiels 2:

Im Folgenden hat für mich gearbeitet:

// scenario 2 MY WAY
// tran starts
e = new MyEntity();
e = em.merge(e); // re-assign to the same entity "e"

//access e from jsp and it will work dandy!!

Answer 9

Wenn man durch die Antworten gibt es einige Details in Bezug auf `Cascade‘ und id Generation fehlen. Siehe Frage

Auch ist es erwähnenswert, dass Sie separate Cascade Anmerkungen für die Zusammenführung und persistierende haben können. Cascade.MERGE und Cascade.PERSIST, die je nach dem verwendeten Verfahren behandelt werden

Die Spezifikation ist dein Freund;)

Answer 10

Ich fand diese Erklärung von dem Hibernate docs erhellend, weil sie einen Anwendungsfall enthalten:

  

Die Nutzung und Semantik von merge () scheinen für neue Benutzer verwirrend. Erstens, solange man nicht in einem Unternehmen-Manager versuchen, in einem anderen neuen Unternehmens-Manager geladen Objektzustand zu verwenden, sollten Sie nicht brauchen merge () zu verwenden, an allen . Einige ganzen Anwendungen werden nie diese Methode verwenden.

     

fusionieren Regel () wird in dem folgenden Szenario verwendet:

     

  
• Die Anwendung lädt ein Objekt in der ersten Einheit-Manager
  
• das Objekt an die Präsentationsschicht übergeben up
  
• einige Änderungen vorgenommen werden, um das Objekt
  
• wird das Objekt wieder auf die Business-Logik-Schicht übergeben
  
• bleibt die Anwendung diese Änderungen durch merge () aufrufen, in einer zweiten Einheit-Manager
  

     

Hier ist die genaue Semantik des merge ():

     

  
• , wenn es eine verwaltete Instanz mit der gleichen Kennung ist derzeit mit dem Persistenzkontext verbunden ist, um den Zustand des gegebenen Objekts auf die verwaltete Instanz kopieren
  
• wenn es derzeit keine verwaltete Instanz mit dem Persistenz-Kontext verbunden ist, versuchen Sie es aus der Datenbank zu laden oder eine neue verwaltete Instanz erstellen
  
• die verwaltete Instanz zurückgegeben
  
• die angegebene Instanz wurde nicht mit dem Persistenz-Kontext verbunden, bleibt es frei stehendes und wird in der Regel verworfen
  

Von: http: //docs.jboss. org / hibernate / EntityManager / 3.6 / Referenz / en / html / objectstate.html

Answer 11

  JPA

ist unbestreitbar eine große Vereinfachung in der Domäne des Unternehmens   Anwendungen auf der Java-Plattform. Als Entwickler, der musste   fertig mit den Feinheiten des alten Entity Beans in J2EE bis ich sehe   Einbeziehung der JPA unter den Java EE Spezifikationen als ein großer Sprung   nach vorne. Während jedoch tiefer in die JPA Details einzutauchen finde ich   Dinge, die nicht so einfach sind. In diesem Artikel befasse ich mich mit Vergleich   der Merge der EntityManager persistieren und Methoden, deren überlappende   Verhalten kann zu Verwirrung führt nicht nur zu einem Neuling. Außerdem I   schlägt eine Verallgemeinerung, die beiden Methoden als Sonderfälle einer sieht   allgemeinere Verfahren kombinieren.

Persistierende Entitäten

Im Gegensatz zu dem Verschmelzungsverfahren der persistieren Methode ist ziemlich einfach und intuitiv. Das häufigste Szenario der Nutzung des persistieren Verfahren zusammengefasst werden kann, wie folgt:

"Eine neu erstellte Instanz der Entity-Klasse ist auf das Verfahren fortbestehen übergibt. Nach dieser Methode zurückgibt, wird die Einheit verwaltet und zum Einfügen in die Datenbank geplant. Es befindet sich auf oder vor der Festschreibung der Transaktion geschehen kann oder wenn die Flush-Methode genannt wird. Wenn das Unternehmen ein anderes Unternehmen über eine Beziehung mit der PERSIST Kaskadenstrategie dieses Verfahren auch angewendet markiert verweist. "

Die Spezifikation geht mehr ins Detail, aber sie erinnern ist nicht entscheidend, da diese Angaben mehr oder weniger exotische Situationen decken nur.

fusionierenden Unternehmen

Im Vergleich zu beharren, die Beschreibung des Verhaltens der Zusammenführung ist nicht so einfach. Es gibt kein Hauptszenario, wie es im Fall bestehen bleiben ist, und ein Programmierer muß alle Szenarien, um daran erinnern, einen korrekten Code zu schreiben. Es scheint mir, dass die PPV-Designer eine Methode, deren Hauptanliegen (als Gegensatz zu der persistieren Methode, die beschäftigt sich mit neu geschaffenen Einheiten in erster Linie.) Von einem der Merge-Methode der Hauptaufgabe ist, zu übertragen, um den Zustand würde Umgang mit frei stehende Einheiten haben wollte nicht verwaltete Entität (als Argument übergeben) zu seinem Gegenstück in der verwalteten Persistenzkontext. Diese Aufgabe jedoch teilt weiter in mehrere Szenarien, die die Verständlichkeit des gesamten Verfahrens, das Verhalten verschlechtern.

Statt die Absätze aus der JPA-Spezifikation zu wiederholen Ich habe ein Flussdiagramm bereit, das schematisch das Verhalten des Merge-Verfahrens zeigt:

Wenn also sollte ich anhalten und wenn merge?

bestehen

• Sie wollen, dass die Methode immer eine neue Entität erstellt und aktualisiert nie eine Einheit. Andernfalls löst die Methode eine Ausnahme als Folge des Primärschlüssel Verletzung der Eindeutigkeit.
• Batch-Prozesse, Einheiten in einer Stateful Weise Kosten (siehe Gateway-Muster).
• Performance-Optimierung

fusionieren

• Sie wollen die Methode entweder Einsätze oder aktualisiert eine Einheit in der Datenbank.
• Sie wollen Entitäten in einer stateless Weise zu handhaben (Datenübertragungsobjekte in Diensten)
• Sie möchten ein neues Element einzufügen, die einen Verweis auf ein anderes Unternehmen haben kann, die noch sein kann, aber nicht erstellt (Beziehung markiert MERGE werden muss). Zum Beispiel das Einfügen ein neues Foto mit einem Verweis auf entweder ein neues oder ein bereits existierenden Album.

Answer 12

Szenario X:

Tabelle: Spitter (One), Tabelle: Spittles (Many) (Spittles ist Eigentümer der Beziehung mit einem FK: spitter_id)

Dieses Szenario führt zu Einsparung: Die Spitter und beide Spittles wie von Same Spitter Besitz

.

        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.addSpittle(spittle3); // <--persist     
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

Szenario Y:

Dies wird die Spitter speichern, werden die 2 Spittles speichern Aber sie werden das gleiche Spitter nicht auf!

        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.save(spittle3); // <--merge!!       
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

Answer 13

Eine weitere Beobachtung:

merge() nur um eine automatisch generierte ID (getestet auf IDENTITY und SEQUENCE) sorgen, wenn ein Datensatz mit einer solchen ID bereits in der Tabelle vorhanden ist. In diesem Fall merge() wird versuchen, den Datensatz zu aktualisieren. Wenn jedoch eine ID nicht vorhanden ist oder nicht alle vorhandenen Datensätze übereinstimmt, merge() wird es völlig ignorieren und db bittet um einen neuen zu vergeben. Dies ist manchmal eine Quelle einer Reihe von Fehlern. Nicht merge() verwenden, um eine ID für einen neuen Datensatz zu erzwingen.

persist() auf der anderen Seite wird nie lassen Sie sogar eine id es passieren. Es wird sofort scheitern. In meinem Fall ist es:

  

Verursacht durch: org.hibernate.PersistentObjectException: freistehende Einheit   geben anhalten

Hibernate-JPA javadoc hat einen Tipp:

  

Wirft : javax.persistence.EntityExistsException - wenn das Unternehmen   ist bereits vorhanden. (Wenn das Unternehmen bereits vorhanden ist, die   EntityExistsException kann geworfen werden, wenn der Betrieb fortbestehen ist   aufgerufen wird, oder die EntityExistsException oder andere PersistenceException   kann bei Flush oder begehen Zeit geworfen werden.)

Answer 14

Sie haben hier kommen um Rat, wenn verwenden, besteht und wenn verwenden fusionieren . Ich denke, dass es die Situation abhängt. Wie wahrscheinlich ist es, dass Sie einen neuen Datensatz zu erstellen, und wie schwer es ist, persistenten Daten abrufen

Lassen Sie uns annehmen können Sie einen natürlichen Schlüssel / Bezeichner verwenden.

• Daten muss beibehalten werden, aber ab und zu ein Datensatz vorhanden ist und ein Update wird gefordert. In diesem Fall könnten Sie ein beharren versuchen und wenn es eine EntityExistsException wirft, schauen Sie es auf und die Daten kombinieren:

  try {EntityManager.persist (entity)}

  catch (EntityExistsException Ausnahme) {/ * abrufen und fusioniert * /}

• persistente Daten aktualisiert werden muss, aber hin und wieder gibt es keine Aufzeichnungen für die noch Daten. In diesem Fall sehen Sie es auf, und machen Sie einen fortbestehen, wenn das Unternehmen fehlt:

  entity = EntityManager.find (key);

  if (Einheit == null) {EntityManager.persist (Einheit); }

  else {/ * merge * /}

Wenn Sie nicht natürliche Schlüssel / Kennung verfügen, werden Sie eine härtere Zeit, um herauszufinden, ob das Unternehmen vorhanden ist oder nicht, oder wie es nachzuschlagen.

Die verschmilzt mit auf zwei Arten behandelt werden, auch:

1. Wenn die Änderungen in der Regel klein sind, wenden sie auf die verwaltete Einheit.
2. Wenn Änderungen üblich sind, die ID aus der persistenten Einheit kopieren, sowie unveränderten Daten. Dann ruft EntityManager :: merge (), um den alten Inhalt zu ersetzen.

Answer 15

persistieren (entity) sollte mit völlig neuen Einheiten verwendet werden, um sie zu DB hinzuzufügen (wenn Einheit existiert bereits in der DB wird es EntityExistsException Wurf sein).

merge (Einheit) verwendet werden soll, Einheit zurück zur Persistenz Kontext zu setzen, wenn das Unternehmen abgelöst wurde und geändert wurde.

Wahrscheinlich persist erzeugt INSERT SQL-Anweisung und SQL-Anweisung UPDATE fusionieren (aber ich bin mir nicht sicher).