Hibernate löscht jeden Datensatz einzeln?

[-MacNuke-]

Hallo.

Ich habe folgendes Mapping:

Room

    @OneToMany(mappedBy="room", cascade = {CascadeType.ALL}, fetch = FetchType.LAZY)
    @JoinColumn(name = "ROOM_ID")
    @Cascade({org.hibernate.annotations.CascadeType.DELETE_ORPHAN})
    public List<Architecture> getArchitecture() {
        return architecture;
    }

und

Architecture

    @ManyToOne(fetch = FetchType.LAZY)
    @OnDelete(action = org.hibernate.annotations.OnDeleteAction.CASCADE)
    @JoinColumn (name="ROOM_ID", nullable = false)
    public Room getRoom() {
        return room;
    }

Davon habe ich noch ein paar mehr Beziehungen, die alle gleich aussehen. Wenn ich den Raum jetzt lösche, dann ruft Hibernate erst mal komplettet alles per SELECT ab und dann löscht er auch noch JEDEN Datensatz EINZELN anhand der ID davon. Das ist etwas seltsam.

Im Prinzip bräuchte es doch nur "delete ... where ROOM_ID = ?" machen.

Geht das irgendwie?

Danke

 

[byte]

Bin mir nicht sicher, obs hier was bringt, aber bei der Benutzung von Bag Semantic (List mit @OneToMany ohne @IndexColumn) erzeugt Hibernate häufig unnützes SQL. Ich empfehle mal auf List Semantic zu gehen (falls das möglich ist in Deinem Projekt), evtl. bringt das den gewünschten Effekt.

 

[-MacNuke-]

Hmm... war mir noch gar nicht bewusst, dass es da einen Unterschied gibt. Ich dachte er sortiert das immer nach ID...

Kann ich bei IndexColumn auch die id nehmen, oder MUSS ich eine extra Spalte nehmen?

 

[byte]

Den PK darfst Du AFAIK nicht nehmen. Bei List Semantik wird ja die Reihenfolge der Elemente in der Liste explizit über die Index-Column persistiert. Das wird wohl mit der PK nicht gehen.

 

[-MacNuke-]

Hmm... OK. Mangels get(index) kann ich dann ja auch kein HashSet nehmen...

Na mal probieren, wie das mit IndexColumn sich so auswirkt.

 

[-MacNuke-]

Jetzt hab ich bei Room das @JoinColumn(name="Position") hinzugefügt und nun kann ich gar nicht mehr löschen, weil alle Einträge in der Tabelle in der Position-Spalte NULL sind...

 

[byte]

Ich habe mich auf obiges Beispiel bezogen, und da benutzt Du List. HashSet ist keine List, sondern ein Set. Set-Semantik ist ein ganz anderes Kapitel (verhält sich auch anders als Bag-Semantik).

 

[-MacNuke-]

Ich habe mich auf obiges Beispiel bezogen, und da benutzt Du List. HashSet ist keine List, sondern ein Set. Set-Semantik ist ein ganz anderes Kapitel (verhält sich auch anders als Bag-Semantik).

Ne, sorry, ich bin nur darauf gekommen, weil ich das in der Doku so gelesen habe. Die Online-Doku von Hibernate lässt ja ziemlich zu wünschen übrig. Code-Auszüge die bis zur Funktionslosigkeit runtergekürzt wurden...

Aber er nummeriert die IndexColumn leider nicht selbst.

 

[byte]

Die Doku könnte besser sein, ja. Aber sie ist immer noch besser als die vieler anderer Frameworks. Die beste Doku hat immer noch Spring.

Wenn Du die IndexColumn richtig konfiguriert hast, dann wird die automatisch gefüllt. Pass auf, dass sie auf der richtigen Seite steht bei bidirektionalen Verbindungen.

 

[-MacNuke-]

Hmm... ich hatte sie jetzt so:

@OneToMany(mappedBy="room", cascade = {CascadeType.ALL}, fetch = FetchType.LAZY)
    @JoinColumn(name = "ROOM_ID")
    @Cascade({org.hibernate.annotations.CascadeType.DELETE_ORPHAN})
    @IndexColumn(name = "POSITION")
    public List<Architecture> getArchitecture() {
        return architecture;
    }

Ist das da falsch?

 

[byte]

Hab ich ehrlich gesagt vergessen, ob das nun auf die Owning Site gehört oder auf die andere. Und ich bin auch zu faul, das jetzt nachzugucken. Steht alles in der Doku.

 

[-MacNuke-]

Na mal heute Abend ins Hibernate in Action Buch gucken. Ich hoffe da steht es halbwegs korrekt drinnen beschrieben... (wobei auch in dem Buch nicht wenig Fehler drinnen sind )

 

[MacNuke@woanders]

Hmm.... also ich werde aus allem nicht schlau.

Laut dem Hibernate-Buch sieht das dann so aus, dass die Unterklasse dann gar keine eigene ID hat, sondern diese dann quasi aus ROOM_ID und POSITION besteht. Aber wie man das bei Annotations setzt, das verschweigt das Buch auch gekonnter weise ;-)

Zur Online-Doku hab ich mich ja schon geäußert, die ist recht nichtssagend...

Na ich werd das Löschen hier dann erst mal manuell machen, damit das erst mal vom Tisch ist...

Das Andere muss ich dann später noch mal sehen, ob sich das irgendwann noch mal aufklärt...