JPA-Aktualisierung der Bidirektionalen Assoziation

Nehmen wir an, wir haben die folgenden Entitäten:

    @Entity
    public class Department {

        @OneToMany(mappedBy="department")
        private List<Employee> employees;
    }

    @Entity
    public class Employee {

        @ManyToOne
        private Department department
    }

Ist es verständlich auf ein update, das wir halten müssen, um beide Seiten der Beziehung wie folgt:

Employee emp = new Employee();
Department dep = new Department();
emp.setDepartment(dep);
dep.getEmployees().add(emp);

Alles gut bis jetzt. Die Frage ist, sollte ich mich bewerben merge-auf beiden Seiten, wie folgt, und ich vermeiden, dass die zweite Verschmelzung mit einer Kaskade?

entityManager.merge(emp);
entityManager.merge(dep);

Oder ist das Zusammenführen der besitzenden Seite genug? Auch sollten diese Zusammenführungen geschehen innerhalb einer Transaktion oder EJB? Oder tun es auf eine einfache controller-Methode mit getrennten Entitäten ist genug?

Wenn Sie die Interaktion mit der Datenbank haben, sollten Sie innerhalb einer Transaktion. Das ist wahr, unabhängig davon, ob Sie mit JPA oder nicht. Es spielt keine Rolle, ob eine Transaktion explizit oder implizit gestartet, durch einen Aufruf einer EJB; beide werden die Arbeit tun.
Was TomAnderson sagte, ist fast immer der Fall. Die Ausnahme ist, wenn Sie eine finden, und Sie finden mit einer Sperre andere als LockModeType.NONE.

InformationsquelleAutor ChrisGeo | 2013-11-19

12

Die Frage ist, sollte ich mich bewerben merge-auf beiden Seiten, wie folgt, und ich vermeiden, dass die zweite Verschmelzung mit einer Kaskade?

Können Sie die cascade-annotation element zu verbreiten, die Wirkung einer operation verbundene Einrichtungen. Die cascade-Funktionalität wird typischerweise verwendet, in der Eltern-Kind-Beziehungen.

Den merge Vorgang wird kaskadiert auf Personen verwiesen wird, die von Beziehungen aus Department wenn diese Beziehungen wurden kommentiert mit der cascade element Wert cascade=MERGE oder cascade=ALL annotation.

Bidirektionale Beziehungen zwischen verwalteten Einheiten wird beibehalten, basierend auf Verweise im Besitz der besitzenden Seite (Employee) von der Beziehung. Es ist der Entwickler in der Verantwortung halten die in-memory-Verweise auf der zugehörigen Seite (Employee) und denjenigen, die auf der inversen Seite (Department) im Einklang mit einander, wenn Sie sich ändern. Also, mit unter eine Reihe von Anweisungen, die Beziehung wird synchronisiert die Datenbank mit einem einzigen merge:
```
Employee emp = new Employee();
Department dep = new Department();
emp.setDepartment(dep);
dep.getEmployees().add(emp);
...
entityManager.merge(dep);
```
Diese änderungen werden an die Datenbank in die Transaktion ein commit. Die in-memory-Zustand der Entitäten synchronisiert werden können, um die Datenbank zu anderen Zeiten als gut, wenn eine Transaktion aktiv ist, indem Sie mit der EntityManager#flush Methode.
- "Bidirektionale Beziehungen zwischen verwalteten Einheiten wird beibehalten, basierend auf Verweise im Besitz der besitzenden Seite (Mitarbeiter) der Beziehung." Tut dies bedeuten, dass Sie die Zusammenführung der besitzenden Seite (Mitarbeiter)? Oder Sie nur Zusammenführen der Seite aus, wo Sie wollen, gelten die cascade-Effekt?
- Sie müssen Zusammenführen der Seite aus, wo Sie wollen, gelten die cascade-Effekt. Sie müssen Zusammenführen Department und die änderungen werden kaskadiert, um die damit verbundenen employees.
- Es gibt zwei separate Regeln, die hier am Werk. Erstens, welche Objekte in die Datenbank gespeichert wird, wird bestimmt durch cascade Attribute auf Beziehungen. Zweitens, in welchem Zustand bekommt die auf der Datenbank gespeichert, die für jedes Objekt wird bestimmt durch den Zustand des Objekts auf der besitzenden Seite. Also, wenn Sie Zusammenführen, die Department, und die employees Eigenschaft markiert ist, als cascading verschmilzt, dann die Employees werden zusammengeführt. Und wenn die Employees Staaten korrekt sind, dann werden die richtigen Daten in die Datenbank geschrieben.
InformationsquelleAutor Debojit Saikia
3

Haben Sie da eine bestehen - Betrieb (aus mit em.merge()). Das verharren eines neuen Mitarbeiters übernimmt nicht bedeuten, dass die Abteilung auch beibehalten (Sie haben keine Kaskadierung), so wird eine Ausnahme geworfen, weil ein anderer Grund (einfach probieren Sie es aus und poste die Ausnahme).Um zu vermeiden, dass Sie entweder fügen Sie eine cascading-Typ, oder verharren Sie beide (wie in deinem Beispiel).

Zu deiner Frage: das einzige Teil, als wäre der besitzenden Seite.
In der JPA 2.0 Spezifikation, Chapter 3 Entity Operations => 3.2.4 Syncrhonization to the Database ist der folgende:

Bidirektionale Beziehungen zwischen verwalteten Einheiten wird beibehalten
basierend auf Verweise, die von den Besitz-Seite der Beziehung. Es ist
die Entwickler in der Verantwortung halten die in-memory-Verweise
auf der besitzenden Seite und denjenigen auf der umgekehrten Seite, im Einklang mit
jede andere, wenn Sie sich ändern. Im Falle der unidirektionalen one-to-one
und eins-zu-viele-Beziehungen, es ist der Entwickler verantwortlich
um sicherzustellen, dass die Semantik der Beziehungen eingehalten werden.[29]

Im Zusammenhang mit der Notwendigkeit einer Transaktion: ja, Sie benötigen für den merge-Vorgang einer aktiven Transaktion. Auszug aus der JPA-2-Spezifikation:

Den persist, merge, entfernen, und aktualisieren Sie die Methoden müssen aufgerufen werden, die innerhalb
einen Transaktionskontext, wenn ein Unternehmen einen manager mit einem
transaction-scoped persistence context verwendet wird. Wenn es keine
Transaktions - Kontext, die
javax.die Persistenz.TransactionRequiredException geworfen.

Auf, wie eine Transaktion gestartet wird/wie Sie starat einer Transaktion: es kommt auf die Art der EntityManager (auf die Art und Weise, wie Sie eines bekommen). In EJB-es ist viel einfacher zu handhaben, die für Allgemeine Situationen. Auch, laut der Dokumentation der merge-Methode, eine TransactionRequiredException geworfen wird, if invoked on a container-managed entity manager of type PersistenceContextType.TRANSACTION and there is no transaction.

InformationsquelleAutor Andrei I

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.