Discussion :

[zhamdi]

Bonjour à tous,

J'ai créé une classe utilitaire pour supprimer les entrées dans une relation one to many qui ne figurent plus dans le Set. Par exemple pour la classe Prof et Eleve, en supprimant un eleve de la liste, on est obligé d'aller effacer l'eleve de la base manuellement si on veut faire un merge() sur le prof. Le probleme es bien connu et TopLink a une solution: http://forums.oracle.com/forums/thre...sageID=1707487 qui est spécifique (donc plus dans le cadre de JPA). Dans un forum Hibernate ils disent qu'on doit supprimer les elements du PersistentSet (le Set original qui a servi à la lecture de la base) pour pouvoir avoir un effacement automatique. La théorie c'est bien, mais perso j'y suis pas parvenu.

Ceci dit, pour etre 100% JPA, on peut imaginer une classe qui intercepte les merge() et fait le travail qu'il faut sur les dépendances. Cette classe je l'ai ecrit, j'ai juste un problème à rejoindre la managed transaction ejb3 pour effacer dans le meme scope que la methode. Eh oui!, il faut que ca se passe dans la même transaction que le merge sinon ca n'a pas de sens.

Quelqu'un saurait comment faire pour acceder à la transaction dans un @PreUpdate ?. Aujourd'hui je lance ma classe directement dans mon code de session, le probleme c'est que c'est "workaround" JPA et n'a rien à voir avec la logique de l'appli. Peut être un intercepteur Spring serait la solution, mais mettre du spring rien que pour ca me parait tout de même un peu crado.

J'ai posté une query au forum d'hibernate: http://forum.hibernate.org/viewtopic...376486#2376486

Si vous avez une idée, faites moi savoir svp,
Zied Hamdi
www.into-i.fr

[JeitEmgie]

J'ai posté une query au forum d'hibernate: http://forum.hibernate.org/viewtopic...376486#2376486

Si vous avez une idée, faites moi savoir svp,
Zied Hamdi
www.into-i.fr

a priori, je dirais que si une fonctionnalité au niveau @Entity a besoin d'accéder au @Repository, c'est qu'elle n'est pas à sa place…

"déplacer les élèves" : n'est-ce pas plutôt du ressort d'une couche "service" qui par définition, elle, connaît le @Repository…


FYI
Hibernate a le
@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
mais bien sûr ce n'est plus 100% JPA…

[zhamdi]

Salut FYI,

"déplacer les élèves" : n'est-ce pas plutôt du ressort d'une couche "service" qui par définition, elle, connaît le @Repository…

Nous nous sommes habitués dans un environnement ioc d'avoir toujours accès au contexte. Ici nous avons un évennement qui est décenché dans un contexte mais qui bizarrement ne sais plus d'où il vient (n'a plus accès à ce contexte).

Merci pour le hint hibernate @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN), TopLink a aussi un flag qui indique le même comportement (IsPrivateOwned). Mais quand on est sous JPA et qu'on veut étendre le système, on ne peut plus rien faire (sans passer dans les couches specifiques).

Il set peut être judicieux de dire: tout ce qui va acceder à la base doit être dans les session beans. Ok mais cette restriction n'a de sens que des ft business. Une ft générique qui étend le modele EJB par exemple pour journaliser les operations, devrait etre hors des classes qui spécifient la logique d'appli, c'est dans le pattern AOP...