Gestion du CascadeType

Bonjour à tous les développeurs. J'ai un soucis, qui me surprends malgré tout.
Voici une annotation JPA dans un classe que j'ai appelé " Contribuable "

Code:

---

1 2 3 4

@OneToOne(cascade = CascadeType.ALL) @JoinColumn(name = "idPieceIdentite", nullable = false) private PieceIdentite pieceIdentite;

---

Cette annotation me permet d'exprimer une relation unidirectionnelle entre la classe Contribuable et la classe PieceIdentite (une PieceIdentite n'a donc pas connaissance de son propriétaire). Ceci marche bien entendu lors de l'insertion dans la base de données (persit) d'une entité de contribuable; Mais lors d'une mise à jour (merge), EclipseLink me renvoie l'erreur ci dessous

Code:

---

1 2 3 4 5 6 7

WARNING: DTX5014: Caught exception in beforeCompletion() callback: Local Exception Stack: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '497563529' for key 'UNQ_PIECEIDENTITE_0' Error Code: 1062 Call: INSERT INTO PIECEIDENTITE (ID, DATEDELIVRANCE, LIEUDELIVRANCE, NUMERO, TYPE) VALUES (?, ?, ?, ?, ?)

---

il existe bien entendu une contrainte d'unicité sur le numéro d'une pièce d'identité. Pourquoi justement EclipseLink essaie t-il de faire une insertion dans cette table au lieu d'une mise à jour. Si je change le numéro de la pièce d'identité une nouvelle ligne est insérée dans la table concernée, alors que c'est une mise à jour qui est effectuée sur le contribuable. Pourquoi une nouvelle insertion lors d'une mise à jour ? :calim2: Merci d'avance pour toute vos contributions.

Fais voir le code de mise à jour.

Voici ce que je fais :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

PieceIdentite p = new PieceIdentite(); p.setNumero(numero); p.setType(type); p.setDateDelivrance(date); p.setLieuDelivrance(lieu); // Je récupère ici l'ancien Id autogénéré p.setId(contribuable.getPieceIdentite().getId()); contribuable.setPieceIdentite(p);   ContribuableDelegate.edit(contribuable); //edit appel le merge

---

Tu devrais récupérer ton objet via une requete ou un find.
Ensuite tu le modifies puis tu le merges.

salut,
crees tu un nouveau contribuable?
car ce serait judicieux de faire Pieceidentite piecedidentite = contribuable.getPiecedidentite(), et la tu pourras manipuler la piece d´identité.
a la fin faire merge.
Le code ContribuableDelegate.edit(contribuable); peux-tu nous le montrer?
Eric

Je précise que ceci est fait à partir d'un client Swing qui utilise une interface distante pour accéder à un EJB déployé sur Glassfish

Je vais toute suite essayer la proposition de jeffray03 en passant voici le code ContribuableDelegate.edit(contribuable)

Code:

---

1 2 3 4 5 6 7 8 9 10

public static void edit(Contribuable contribuable) { getContribuableFacadeRemote().edit(contribuable); }   private static ContribuableFacadeRemote getContribuableFacadeRemote() { ContribuableFacadeRemote contribuableRemote; contribuableRemote = (ContribuableFacadeRemote) ServiceLocator.getInstance().getRemoteInterface("contribuableFacade-ejb"); return contribuableRemote; }

---

et voici à quoi ressemble la fonction edit

Code:

---

1 2 3 4

public void edit(T entity) { getEntityManager().merge(entity); }

---

info supplémentaire: Même si je n'ai pas l'intention d'apporter une modification à la pièce d'identité, mais seulement au contribuable, EclipseLink essaiera toujours une nouvelle insertion de pieceIdentité.

Citation:

---

Envoyé par fr1man

Tu devrais récupérer ton objet via une requete ou un find.
Ensuite tu le modifies puis tu le merges.

---

En dehors de la remarque que j'ai mentionné ci-dessus, il y a aussi le fait qu'une seule IHM gère un contribuable et sa pièce d'identité. Je pensais que le CascadeType.All voulait dire insérer en cascade, mettre à jour en cascade (et non << mettre à jour et insérer >>...), etc. :?

Citation:

---

info supplémentaire: Même si je n'ai pas l'intention d'apporter une modification à la pièce d'identité, mais seulement au contribuable, EclipseLink essaiera toujours une nouvelle insertion de pieceIdentité.

---

oui mais, ce sera le meme object recuprer dans la base de données, avec new c´est tout une autre reference avec un Id deja existant.

Citation:

---

Envoyé par jeffray03

oui mais, ce sera le meme object recuprer dans la base de données, avec new c´est tout une autre reference avec un Id deja existant.

---

Je vous ai parfaitement compris (à mon avis) dès votre première suggestion. Mais le problème persiste même si je ne réalise aucune action sur l'instance de pieceIdentite; en me contentant par exemple de modifier uniquement l'attribut nom du contribuable et de faire en suite le merge (au travers de la fonction edit). A moins que le problème dans ce cas vienne du fais que l'entity est détaché (j'y accède par une Remote Interface dans mon client swing).

:D Mieux vaux tard que jamais. J'ai finalement préféré setter mon instance dans l'ejb (après un find) et non plus dans mon interface swing. cela me rassure que je travail sur une instance de contribuable retourner par EclipseLink. voici ce que je fais dans l'ejb

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public Contribuable edit(Contribuable c){ Contribuable contribuable = em.find(Contribuable.class, c.getId()); contribuable.setNom(c.getNom()); contribuable.setPrenom(c.getPrenom()); ... ... ...   contribuable.getPieceIdentite().setDateDelivrance(c.getPieceIdentite().getDateDelivrance()); contribuable.getPieceIdentite().setLieuDelivrance(c.getPieceIdentite().getLieuDelivrance()); contribuable.getPieceIdentite().setNumero(c.getPieceIdentite().getNumero()); contribuable.getPieceIdentite().setType(c.getPieceIdentite().getType()); em.merge(contribuable); return contribuable; }

---

C'est vrai que je ne comprends pas toujours ce qui change l'instance de contribuable récupéré dans swing.