Le 04/03/2013 02:30, Adrien Cheype a écrit :
Bonjour Eric,
Nous avons mis à jour qu'un côté des associations pour l'unique raison de simplifier le code. Mais tu as raison, cette manière de faire entraîne des graphs de persistance incohérents. Si je comprends bien le post que tu donnes en exemple, quand Hibernate détecte des incohérences, il semble prendre en compte la version de l'entité propriétaire de l'association (par exemple dans une association 1-n, l'entité du côté 1).
Seulement ce ne semble pas être ce qui arrive avec personne#lotsDroits par exemple. En effet, c'est bien l'entité non propriétaire de la relation qui est mise à jour et une fois la session hibernate rechargée, nous nous retrouvons bien avec graph cohérent avec les éléments précédemment ajoutés. En regardant la doc d'hibernate que j'ai trouvée, ils parlent en effet bien qu'il fasse mettre à jour les deux côtés, mais disent seulement qu'il se servent de l'entité propriétaire pour résoudre les conflits. http://docs.jboss.org/hibernate/core/4.1/manual/en-US/html/ch01.html#tutoria... La relation personne#lotsDroits est un peu compliquée, mais j'ai bien l'impression que c'est le coté "propriétaire" de la relation (avec le cascade) par rapport à campagne#personnesDroits qui ne l'est pas).
J'ai donc plutôt l'impression que quand le graph est incohérent, il prend d'abord en compte la propriété qui a été mise à jour et si les deux l'ont été (de manière différente du coup), il prend la version de l'entité propriétaire.
En tout cas, n'hésite pas à corriger la façon de mettre à jour ces associations... surtout si cela peut entraîner des effets de bord avec Hibernate Search. J'ai testé en mettant à jour les deux cotés, mais ca n'aide pas, car aucun modification n'est détecté du coté 'non propriétaire' de la relation (campagne#personnesDroits dans mon cas). Donc je n'ai pas commité ce code.
Par contre, les relations bi-di, même si elle ne servent pas vraiment dans le code de cantharella parfois, servent à mettre certaines annotations sur les associations pour la modification de l'index lors de la modifications d'entités liées.
Adrien
PS : en passant ManageUtilisateurPage.java est un bon exemple Wicket de comment inutilement compliquer les développements en utilisant des listes temporaires. C'est un artefact qui reste par rapport aux autres interfaces qui gèrent bien plus simplement des listes de même type.
Ok. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com