JPA Seriendruck-Ergebnisse in doppelter Eintrag von ausländischen Unternehmen

FRAGEN:

Weiß jemand, wie man Zusammenführen, ohne EntityManager versuchen Sie zu re-legen Sie die ausländische Person?

SZENARIO:

Nur um ein Szenario, das am ehesten mein Fall: ich habe zwei Entitäten

@Entity
@Table(name = "login", catalog = "friends", uniqueConstraints =
@UniqueConstraint(columnNames = "username"))
public class Login implements java.io.Serializable{

   private static final long serialVersionUID = 1L;
   @Id
   @GeneratedValue(strategy = IDENTITY)
   @Column(name = "id", unique = true, nullable = false)
   private Integer id;
   @Column(name = "username", unique = true, nullable = false, length = 50)
   private String username;
   @Column(name = "password", nullable = false, length = 250)
   private String password;
}

@Entity
@Table(name = "friendshiptype", catalog = "friends")
public class FriendshipType implements java.io.Serializable{

   private static final long serialVersionUID = 1L;
   @Id
   @GeneratedValue(strategy = IDENTITY)
   @Column(name = "id", unique = true, nullable = false)
   private Integer id;
   @OneToOne(fetch = FetchType.LAZY)
   @JoinColumn(name = "username")
   private Login login;
      @Column(name = "type", unique = true, length = 32)
   private String type;
   ...//other fields go here
}

Sowohl die Login Unternehmen und die FriendshipType Entität gespeichert werden, um die Datenbank getrennt. Dann, später, ich brauche, um Seriendruck eine Login Zeile mit einem FriendshipType Zeile. Wenn ich Anrufe entityManager.merge(friendship) es versucht, legen Sie einen neuen Login was natürlich die Ergebnisse in der folgenden Fehlermeldung

Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'myUserName1350319637687' for key 'username'
Error Code: 1062
Call: INSERT INTO friends.login (password, username) VALUES (?, ?)

Meine Frage, ist: wie führe ich zwei Objekte ohne enityManager versucht, wieder das fremde Objekt?

Dies hat wohl nichts zu tun mit dem Problem, aber sollte es nicht sein, @JoinColumn(name = "id"). Alle Beispiele, die ich gesehen habe, join über die id-Eigenschaft.
Simone ich versuchen deinen Vorschlag, aber keine Veränderung.
OK - danke für das lassen mich wissen. Hoffe du bekommst bessere Antworten.

InformationsquelleAutor kasavbere | 2012-10-15

5

Hier ist, wie ich das problem lösen. Ich schließlich die Figur der Grund der Zusammenführung nicht auflösen wird, weil der login.id wird automatisch generiert, durch das JPA. Also da ich wirklich nicht benötigen eine automatisch generierte id-Feld, Entferne ich es aus dem schema und verwenden username als @id Feld:
```
@Entity
@Table(name = "login", catalog = "friends", uniqueConstraints =
@UniqueConstraint(columnNames = "username"))
public class Login implements java.io.Serializable{

   private static final long serialVersionUID = 1L;
   @Id
   @Column(name = "username", unique = true, nullable = false, length = 50)
   private String username;
   @Column(name = "password", nullable = false, length = 250)
   private String password;
}
```
Andere Lösung, die mir einfiel, die ich nicht umsetzen kann aber jemand anderes helfen, sollten Sie brauchen, um einen automatisch generierten id-Feld.

Stattdessen erstellen Sie eine Instanz der Login für die Fusion, erhalten Sie die Instanz aus der Datenbank. Was ich meine ist, statt
```
Login login = new Login(); login.setUsername(username); login.setPassword(password);
```
Tun, eher
```
Login login = loginDao.getByUsername(username);
```
So, ein neues id-Feld wird nicht generiert, wodurch die Einheit scheinbar anders.

Dank und up-votes an alle für die Hilfe, besonders an @mijer for being so geduldig.
- Ich bin froh, dass Sie eine Lösung gefunden haben kasavbere, aber auf lange Sicht glaube ich nicht, dass das entfernen des automatisch generierten id, an einer Beziehung zu arbeiten, war eine gute design-trade-off. Nehmen irgendwann lassen die Idee, eine @ManyToOne Beziehung sinken Sie in Ihrem Kopf (die impedance-mismatch-Probleme sind häufiger als Sie denken, und fallenlassen der PK kann die Lösung nicht sein die nächste Zeit, die Sie auf einer von denen).
- Ich bin mit der username als Primärschlüssel. Wie ich schon erwähnt, in der alternativen Lösung konnte ich sehr gut halten das auto-generierte Feld, wenn ich es brauchte. Ich dachte @ManyToOne könnte irreführend sein, da die realationship ist wirklich @OneToOne. Immer noch, entweder man hat das problem nicht lösen, und ich bin immer noch mit @ManyToOne in meine Lösung-ich habe nicht geändert, es noch zurück.
- Komisch, die @ManyToOne Anmerkung sollte das problem lösen, es sei denn, Sie beharren nicht neue Login Objekte mit Ihren FriendshipType (was Ihr zweiter Vorschlag wäre zu lösen).
InformationsquelleAutor kasavbere

Können Sie machen Sie Ihre @JoinColumn nicht aktualisierbar:

@JoinColumn(name = "login_id", updatable = false) //or
@JoinColumn(name = "username", referencedColumnName = "username", updatable= false)

Oder versuchen, zu aktualisieren /abrufen Login Person wieder vor dem Zusammenführen der FriendshipType:

//either this
entityManager.refresh(friendship.getLogin());
//or this
final Login login = entityManager
          .getReference(Login.class, friendship.getLogin().getId());
friendship.setLogin(login);
//and then
entityManager.merge(friendship);

Aber, wie von anderen vorgeschlagen, ich denke, dass FriendshipType besser wäre, vertreten durch eine @ManyToOne Beziehung oder vielleicht durch eine Einbettbare oder ElementCollection

Update

Noch eine andere option ist die änderung der Besitz-Seite:

public class Login implements java.io.Serializable {
    @OneToOne(fetch = FetchType.LAZY) 
    @JoinColumn(name = "friendshiptype_id")
    private FriendshipType friendshipType;
    //Other stuff 
}

public class FriendshipType implements java.io.Serializable {
    @OneToOne(fetch=FetchType.LAZY, mappedBy="friendshipType")
    private Login login;
    //Other stuff 
}

Dies wird Auswirkungen auf Ihre Daten-Modell (login-Tabelle wird ein friendshiptype_id Spalte, anstatt die andere Weise herum), aber es wird verhindern, dass die Fehler, die Sie bekommen, da Beziehungen stets erhalten bleiben, indem die besitzende Seite.

InformationsquelleAutor Anthony Accioly

1

Haben Sie versucht cascade=MERGE? I. e.
```
@OneToOne(fetch = FetchType.LAZY, cascade=CascadeType.MERGE)
@JoinColumn(name = "username")
private Login login;
```
UPDATE

Eine andere Möglichkeit ist die Verwendung @ManyToOne (es "speichern unter" der Verein ist einzigartig)
```
@ManyToOne(fetch = FetchType.LAZY, cascade=CascadeType.MERGE)
@JoinColumn(name = "username")
private Login login;
```
- Ja, habe ich. Nichts.
- Ist es richtig, dass friendshiptype.login-Feld enthält den Benutzernamen und nicht die login id?
- Das war wahr. Aber ich habe es geändert @JoinColumn(name = "login_id"), die sich in der Datenbank-schema als CONSTRAINT FK_friendshiptype_login_id FOREIGN KEY (login_id) REFERENCES login (id). Aber ich bekomme immer noch den Fehler.
- Sie könnten versuchen @ManyToOne statt @OneToOne?
- Ich habe es gerade ausprobiert mit verschiedenen Permutationen von cascade={CascadeType.MERGE,CascadeType.PERSIST} " - der ganze Satz macht. Keine änderung.
InformationsquelleAutor szhem
0

Können Sie es mit Ihrem original @Id-setup. also
```
 @Id
 @GeneratedValue(strategy = IDENTITY)
 @Column(name = "id", unique = true, nullable = false)
 private Integer id;
```
Können Sie, aber Sie brauchen nicht zu ändern:
```
 @Id
 @Column(name = "username", unique = true, nullable = false, length = 50)
 private String username;
```
Der trick ist, müssen Sie starten durch laden aus der DB, über em.finden(...) oder em.createQuery(...). Dann die id ist garantiert aufgefüllt werden mit dem richtigen Wert aus der DB.

Dann können Sie trennen Sie die Einheit durch die Beendigung einer Transaktion (für ein transaction-scoped entity-manager in einer session-bean), oder durch den Aufruf von em.trennen Sie(ent) oder em.clear(), oder durch serialising der Person und übergeben es über das Netzwerk.

Dann können Sie aktualisieren Sie die Einheit, die ganze Zeit, halten Sie die original-id-Wert.

Dann können Sie call-em.merge(ent) und Sie haben noch immer die richtige id. Ich glaube jedoch, muss das Unternehmen bereits vor-vorhanden in der persistenten Kontext des entity-manager in diesem Augenblick, sonst wird Sie denken, dass Sie eine neue Entität (mit manuell gefüllt-id), und versuchen Sie, LEGEN Sie in Transaktion flush/commit.

Also der zweite trick ist, um sicherzustellen, dass die Entität geladen, an der Stelle der Zusammenführung (über em.finden(...) oder em.query(...) wieder, wenn Sie haben ein neues persistentes Kontext-und nicht dem original).

🙂

InformationsquelleAutor Glen Best

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.