Persistierung in Hibernate(SpringBoot)

[ExceptionOfExpectation]

Hallo,
angenommen ich habe zwei Klassen:

@Entity
@Access(AccessType.FIELD)
public class Cover{
    
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long id;
    
    private String title;
    
    @OneToOne(mappedBy="cover")
    private Page page;
    
    //SETTER & GETTER außer setId()
}
--------------------------------------------
@Entity
@Access(AccessType.FIELD)
public class Page{
    
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long id;
    
    @OneToOne
    @JoinColumn(name="cover_fk")
    private Cover cover;
    
    private byte [] textDocument;
    
    //SETTERS & GETTERS außer setId()
    
}

Eine Cover Klasse hat eine Page Klasse und diese Page Klasse besitzt einen Textinhalt, also es kann alles sein: JSON, DOC, TXT order sonst irgend-ein File. Somit ist diese Page Klasse gleichzeitig die "Owning Side" mit dem FremdSchlüssel. Die Cover Klasse, um die bidirektionale Beziehung aufzubauen, besitzt einen Page Feld mit Markierung "mappedBy". Damit habe ich die Beziehung aus dem Datenbank im Code fast vollständig wiedergegeben.

In der Datenbank habe ich überfüllt eine Menge Cover Datensätze, zu jedem Cover Datensatz möchte ich einen Page Datensatz hinzufügen, aber das alles soll auf der Java Seite stattfinden. Das heißt ich müsste jedesmal eine Cover-Entity aufrufen mit Hilfe von entityManager.find(Cover.class, id) und dann ein neues Objekt Page instanziieren, danach dieses Page Objekt zu dem EntityObjekt Cover hinzufügen und dann beide wieder in der Datenbank speichern. Dafür dachte ich die persist() und merge() Methoden zuverwenden in der Reihenfolge, falls die Reihenfolge unwichtig ist, dann bitte gleich Bescheid sagen. Das hat nicht geklappt, ohne @Transactional lief es nicht, also es wurde nichts persistiert. Meine Frage Dazu lautet:
-Wie kann ich die neue Page-Instanziierung zu der Cover-Entity einfügen und es persistieren, ohne eine jegliche Form von Transactional zu verwenden, auch ohne dabei auf JdbcTemplate zugreifen?

 

[Oneixee5]

Ich verstehe nicht was du möchtest. In der Überschrift steht "Hibernate" aber "JdbcTemplate" gehört zu Spring Data JDBC. JdbcTemplate benutzt man eh nicht mehr so wirklich, eher JdbcClient. @Transactional ist eine Annotation für public Methoden, deren Inhalt in einer Transaktion ausgeführt wird. Bei Hibernate würde man eher ein flush() verwenden. Zusammengefasst: ich werde nicht so richtig schlau aus deiner Beschreibung.

Die Abfolge für das Speichern von Datensätzen in pure Hibernate wäre etwa so:

Transaction tx = session.beginTransaction();
try {
    for (int i = 0; i < 100000; i++) {
        MyEntity myEntity = new MyEntity(...);
        session.save(myEntity);
        if (i % 20 == 0) { // 20 -> JDBC batch size
            // flush inserts and release memory:
            session.flush();
            session.clear();
        }
    } 
    tx.commit();
} catch (...) {
    tx.rollback();
    ...
}

Was wird denn wirklich verwendet: Hibernate, JPA, Spring Data JDBC, ...? Alles durcheinander sollte man nicht machen. So ein Projekt wird unwartbar.

 

[Ullenboom]

Bei JPA muss man IMMER @Transactional beim Schreiben nutzen. Andernfalls gibt es eine Ausnahme.

 

[ExceptionOfExpectation]

Danke,
ich lerne ja nach ihrem Buch. Sehr gute Ausgabe, ich wünschte mir nur Sie hätten MySQL statt PostgreSQL verwendet.

 

[Ullenboom]

Danke für das Kompliment. Ich nutzte aber H2. Bis auf kleine Unterschiede im SQL, kann man aber schnell wechseln.

 

[ExceptionOfExpectation]

Danke für das Kompliment. Ich nutzte aber H2. Bis auf kleine Unterschiede im SQL, kann man aber schnell wechseln.

Ja, dadurch habe ich mich mit PostgreSQL vertraut gemacht. Ansonsten ist es nicht mal ein Kritikpunkt, es gehört zu den persönlichen Vorzügen.

 

[mihe7]

Das heißt ich müsste jedesmal eine Cover-Entity aufrufen mit Hilfe von entityManager.find(Cover.class, id) und dann ein neues Objekt Page instanziieren, danach dieses Page Objekt zu dem EntityObjekt Cover hinzufügen und dann beide wieder in der Datenbank speichern. Dafür dachte ich die persist() und merge() Methoden zuverwenden in der Reihenfolge, falls die Reihenfolge unwichtig ist, dann bitte gleich Bescheid sagen. Das hat nicht geklappt, ohne @Transactional lief es nicht, also es wurde nichts persistiert.

Nicht ganz/unbedingt. So lange die Entity managed ist, werden Änderungen automatisch (spätestens) am Ende der Transaktion auf die DB abgebildet.

D. h. um eine bereits vorhandene, persistente Entity zu ändern, ist weder persist noch merge erforderlich. Es reicht, die Entity aus der DB zu laden (z. B. mit find oder einer Query) und in der Transaktion zu ändern:

Cover cover = em.find(Cover.class, id); // liefert eine managed Entity-Instanz vom Typ Cover
cover.setTitle("X");

Ferner muss man Entities und deren Beziehungen unterscheiden. Du hast zwei Entities, Cover und Page, die in einer 1:1-Beziehung zueinander stehen. Mit dem Setzen der Page eines Covers wird lediglich die Beziehung zwischen den Entities festgelegt.

public void setExistingPage(Long coverId, Long pageId) {
    Cover cover = em.find(Cover.class, coverId);
    Page page = em.find(Page.class, pageId);
    cover.setPage(page);
}

Da dies nur die Beziehung zwischen den Entities betrifft, nicht aber die Page-Entity selbst, können auf diese Weise nicht einfach neue Page-Objekte hinzugefügt werden.

public void setNewPage(Long coverId) {
    Cover cover = em.find(Cover.class, coverId);
    cover.setPage(new Page());
}

Das führt zunächst zu einem Fehler. Damit das funktioniert, persistiert man entweder das Page-Objekt explizit oder man gibt CascadeType.PERSIST (oder ALL) in Cover für die Beziehung zum Page-Objekt an.

@Entity
@Access(AccessType.FIELD)
public class Cover{
  
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long id;
  
    private String title;
  
    @OneToOne(mappedBy="cover", cascade=CascadeType.PERSIST)
    private Page page;
  
    //SETTER & GETTER außer setId()
}

 

[ExceptionOfExpectation]

Nicht ganz/unbedingt. So lange die Entity managed ist, werden Änderungen automatisch (spätestens) am Ende der Transaktion auf die DB abgebildet.

D. h. um eine bereits vorhandene, persistente Entity zu ändern, ist weder persist noch merge erforderlich. Es reicht, die Entity aus der DB zu laden (z. B. mit find oder einer Query) und in der Transaktion zu ändern:

Cover cover = em.find(Cover.class, id); // liefert eine managed Entity-Instanz vom Typ Cover
cover.setTitle("X");

...

Du magst in dem Fall recht haben, aber das würde bedeuten, dass nach jeder Änderung auf die Datenbank zugegriffen werden müsste.

 

[mihe7]

Du magst in dem Fall recht haben, aber das würde bedeuten, dass nach jeder Änderung auf die Datenbank zugegriffen werden müsste.

Nö. Das bedeutet nur, dass Du kein explizites merge()/persist() aufrufen musst. Oder meinst Du etwas anderes?

 

[ExceptionOfExpectation]

Nö. Das bedeutet nur, dass Du kein explizites merge()/persist() aufrufen musst. Oder meinst Du etwas anderes?

ich meine ich greife nach jedem Update auf die Datenbank und das ist nicht optimal.
Stelle dir vor, du hast aus dem Datenbank ein Objekt geholt und dieses Objekt wird von Client verwendet und verändert, so dass er aus dem persistenten Kontext rausgenommen wird.
Danach speichere ich das Objekt, zwei Zugriffe und dazwischen noch viele Änderungen von Außen.

PS.: ich dachte ich hätte den Beitrag schon vor lange abgeschickt

 

[mihe7]

Stelle dir vor, du hast aus dem Datenbank ein Objekt geholt und dieses Objekt wird von Client verwendet und verändert, so dass er aus dem persistenten Kontext rausgenommen wird.
Danach speichere ich das Objekt, zwei Zugriffe und dazwischen noch viele Änderungen von Außen.

Naja, es gilt halt wie immer: kommt darauf an. Für Batch-Updates ist das sicher nicht der geeignete Weg.