Erste Schritte in Richtung JPA

Grüße an alle Leser,

in diesem Artikel berühre ich die grundlegenden Konzepte von JPA und die Lösungen für die Probleme, die wir bewusst erschaffen.

Da Jpa und Hibernate so umfassend sind, werde ich in diesem Artikel direkt auf einige der Hauptprobleme und Ansätze eingehen, die verinnerlicht werden müssen.

Das folgende Bild zeigt die Grundprinzipien, die über JPA bekannt sein sollten.

Programmierer, die mit der JPA-Technologie beginnen, lernen oft die Regeln für Navigationseigenschaften und erstellen dann sofort relationale Datenbanken. Aber vorher muss ich über einige sehr wichtige Konzepte sprechen, die bekannt sein sollten.

Das Oberflächen Arbeitsprinzip von JPA ist wie folgt.

“Child- Parent / Owning -Inverse End” Konzepte

Problem 1 :OneToMany Unidirectional Persistence- ”detached entity passed to persist“.

Das Objekt in Managing Area (oder Persistence Context) möchte eine Operation an einer Zeile ausführen, die sich in der Datenbank befindet. Da steht, wenn du es einfach mitbringst, kann ich auch ein „persist“ werden. Obwohl es an dieser Stelle nicht ganz richtig ist, kann der Autor als Child und das Buch als Parent betrachtet werden. Es ist nicht ganz richtig, weil sie unabhängig erstellt werden können!

Denken Sie einen Moment nach und fragen Sie sich, ob Sie diese Situation wollen.

Eine absurde Lösung: Nach dem Hinzufügen des Autors und des Buchs zur Datenbank werden der Autor und die Bücher aufgerufen, der Autor und die Bücher verknüpft und erneut in der Autorendatenbank gespeichert. Aber das ist wirklich absurd und beinhaltet zu viele unnötige Operationen.

Eine absurdere Lösung: Das Buch wird der Datenbank hinzugefügt und ich rufe es erneut mit der findById-Methode auf, damit ich in Manager Area gelangen und den Autor zuordnen kann, bevor ich es speichere.

Es ist eigentlich so verrückt, wenn ich es jedes Mal hinzufüge, muss ich zuerst die Datenbank durchsuchen.

Das zeigt uns, wie das System selbst mit einfachen Codes verlangsamt werden kann, wenn man nicht aufpasst.

Akzeptable Lösung: Erstellen Sie CascadeType.MERGE und setzen Sie die Regel “Wenn das Buch zusammengeführt wird, wird auch der Autor zusammengeführt”. Denken Sie jedoch daran, dass dieser Prozess auch eine Ressource erfordert, wenn auch nicht so viel wie die oben genannten.

Eine plausible und einfache Lösung: Erstellen Sie ein Buchobjekt mit Autor, verknüpfen Sie sie, speichern Sie zuerst das Buch, dann den Autor. Es ist sinnvoll, zuerst Parent und dann Child zu speichern.

Lazy Initialization Problem mit einem Satz: Ein Proxy-Objekt ersetzt die Associated-Collection, aber ich möchte auch Daten aus der referenzierten Tabelle erhalten!

Absurde Lösung: Verwendung von FetchType.EAGER
Ich denke, die beste Erklärung dazu hat Thorben Janssen gegeben.

“FetchType.EAGER tells your persistence provider to fetch a managed association as soon as you load the entity. So, it gets loaded from the database, whether or not you use the association in your business code. For most of your use cases, that means that you execute a few unnecessary database queries, which obviously slows down your application.”

Eine Lösung: die Verwendung von findById
Wenn die gewünschten Bücher aus der Datenbank erneut aufgerufen werden, bevor die besitzende Entität gespeichert wird, wird die Sitzung(Session) geöffnet und der update durchgeführt.

andere Lösung: die Verwendung von @Transactional
Dies ist eine nützliche Lösung, wird aber normalerweise in Service layer verwendet. Wenn Sie jedoch diese Regel brechen und verwenden möchten, werden Sie sehen, dass eine separate Sitzung geöffnet und für jede Operation ein Aktualisierungsprozess durchgeführt wird, ähnlich dem obigen Punkt.

Gute Lösung: Left Join abrufen
Wir können das Problem mit einer einzigen Operation lösen, indem wir eine jpql-Abfrage schreiben.Dieser Prozess funktioniert nur, wenn er angefordert wird!

Bevor ich den Artikel beende:
Am Anfang des Artikels habe ich erwähnt, dass die unidirektionale Beziehung in den Büchern ohne author_id definiert werden kann. Wenn dies für Ihr Szenario nicht geeignet ist, ist die unidirektionale Manytoone-Beziehung logischer als die unidirektionale Onetomany-Beziehung. Untersuchen Sie das Bild unten. Es gibt noch viel zu lernen und ich schlage vor, sich für einen guten Start auf die Themen im Artikel zu konzentrieren.

LG

Baran Kaplan