Spring Data: Detached Entity passed to persist Fehler

[lam_tr]

Hallo zusammen,

ich bin mal wieder auf ein Problem gestoßen, womit ich gar nicht klar kommen. Ich habe ein BackupPoint Model der sozusagen zwei Verzeichnise als String abspeichert und letztes Document, Registration und Appointment.

@Entity
public class BackupPoint {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "BACKUP_POINT_ID", nullable = false, columnDefinition = "BIGINT")
    private Long id;
   
    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String sourcePath;

    @Column(nullable = false)
    private String targetPath;
   
    @OneToOne(fetch = FetchType.LAZY, cascade={CascadeType.MERGE,CascadeType.REFRESH})
    @MapsId
    private Document document;

    @OneToOne(fetch = FetchType.LAZY, cascade={CascadeType.MERGE,CascadeType.REFRESH})
    @MapsId
    private Registration registration;

    @OneToOne(fetch = FetchType.LAZY, cascade={CascadeType.MERGE,CascadeType.REFRESH})
    @MapsId
    private Appointment appointment;
}

Beim Erstellen des BackupPoint Object setze ich ein in der DB existierendes Document, Registration und Appointment Object mit. Und beim Speichern des BackupPoint Objects bekomme ich folgende Meldung:

Caused by: org.springframework.dao.InvalidDataAccessApiUsageException: detached entity passed to persist: de.dc.fx.model.calendar.Appointment; nested exception is org.hibernate.PersistentObjectException: detached entity passed to persist: de.dc.fx.model.calendar.Appointment

Was hat das zu bedeuten?

An sich sollen die referenzierten Objekte nicht mehr gespeichert werden, d.h. CascadeType Merge und Refresh reicht in dem Sinne oder?

Es sollen jeweils nur die Ids der Objekte in das BackupPoint gespeichert werden, d.h. wenn ich ganz dumme mache könnte ich es auch so ohne Referenzierung machen

@Entity
public class BackupPoint {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "BACKUP_POINT_ID", nullable = false, columnDefinition = "BIGINT")
    private Long id;
   
    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String sourcePath;

    @Column(nullable = false)
    private String targetPath;
   
    @Column(nullable = false)
    private int documentId;
    @Column(nullable = false)
    private int RegistrationId;
    @Column(nullable = false)
    private int appointmentId;
}

Aber das ist auch nicht wirklich das wahre. Was ist da mein Denkfehler und wie kann man es schöner machen?

Vielen Dank schonmal.

Grüße
lam​

 

[httpdigest]

- https://stackoverflow.com/questions/13370221/jpa-hibernate-detached-entity-passed-to-persist
Erste Antwort: "This is a typical bidirectional consistency problem."
Wie sieht die Klasse Appointment aus? Hat sie auch eine Beziehung zu BackupPoint?

 

[lam_tr]

Ja ich habe auch schon gegoogelt und bin leider nicht schlau geworden.

Und zur Appointmint, nein ich hat keine Beziehung zur BackupPoint.ich probiere das nachher aus.

Aber ich denke wenn die Referenzen im BackupPoint schon davor in der DB gespeichert reicht es doch ohne Rück Beziehung zu haben oder?

 

[mihe7]

Was hat das zu bedeuten?

Ich würde mal annehmen, dass das genau das bedeutet, was dort steht. Dein BackupPoint referenziert ein Appointment-Objekt, das sich zum Zeitpunkt des persist im DETACHED-Zustand befindet.

Ohne mir jetzt die Spezifikation anzusehen, finde ich das strange, weil persist für appointment ja nicht kaskadierend ausgeführt wird. Hier hätte ich die MapsId-Annotation in Verdacht, die mit an Sicherheit grenzender Wahrscheinlichkeit falsch an der Stelle ist.

 

[lam_tr]

Vielen Dank euch beiden. Ich habe die MapsId Annotation rausgemacht und jeweils die Referenzen in die Documents, Registrations und Appointments ergänzt. Danach geht's.

Grüße
lam

 

[mrBrown]

jeweils die Referenzen in die Documents, Registrations und Appointments ergänzt

Die dürften aber auch nicht nötig sein, Unidirektional ist meist einfacher und klappt genausogut

 

[mihe7]

Die dürften aber auch nicht nötig sein, Unidirektional ist meist einfacher und klappt genausogut

Ja, ich könnte mich jetzt nicht erinnern, an welcher Stelle wir bidirektionale Beziehungen verwenden würden. Vielmehr bilden wir Aggregate von der Wurzel aus mit unidirektionalen Beziehungen ab, während Beziehungen zwischen Aggregaten nur durch IDs dargestellt werden.