J'ai besoin pour un test de supprimer une volé de donnée avant des les recréer, j'ai donc mis les compos qui vont bien dans mon modèle, je supprime le tout et lors d'une recherche qui n'a rien a voir avec ce que j'ai supprimé plus tôt, je me retrouve avec l'erreur suivante : org.nuiton.topia.TopiaException: Une erreur est apparue pendant le recherche ([...]) : deleted object would be re-saved by cascade (remove deleted object from associations): [mon joli topiaId] J'ai regardé dans le mapping et je vois cascade="all,delete-orphan", pour moi le delete-orphan est compris dans le all, non ? Il existe aussi la valeur all-delete-orphan j'arrive à la même erreur. J'ai supprimé le all, plus l'erreur, mais ce log qui revient très souvent : 2012/02/03 17:29:32 INFO main (DefaultDeleteEventListener.java:204) handling transient entity in delete processing Quelqu'un à la traduction ? D'où ma question : quelqu'un pourrait dire si et auquel cas, pourquoi, le all est nécessaire ? Letellier Sylvain letellier@codelutin.com
Le Fri, 3 Feb 2012 17:37:58 +0100, letellier <letellier@codelutin.com> a écrit :
J'ai besoin pour un test de supprimer une volé de donnée avant des les recréer, j'ai donc mis les compos qui vont bien dans mon modèle, je supprime le tout et lors d'une recherche qui n'a rien a voir avec ce que j'ai supprimé plus tôt, je me retrouve avec l'erreur suivante :
org.nuiton.topia.TopiaException: Une erreur est apparue pendant le recherche ([...]) : deleted object would be re-saved by cascade (remove deleted object from associations): [mon joli topiaId]
Vu que le flush (actions en base) se fait sur le select, il cherche à sauver ton entité en cascade. A priori, les éléments supprimés sont toujours attachés à ton objet dans ce contexte, d'où l'erreur.
J'ai regardé dans le mapping et je vois cascade="all,delete-orphan", pour moi le delete-orphan est compris dans le all, non ?
En fait non, le cascade all permet d'effectuer une cascade sur PERSIST, MERGE, DETACH, DELETE. Un cascade DELETE permet lorsque tu supprime ton objet, de supprimer ses enfants qui portent le cascade. Le delete-orphan lui te garanti juste que si un enfant n'a plus de lien pour une raison x ou y avec son père, il sera supprimé. Il doit bien y avoir des cas tordus où le père ne supprime pas les enfants et le delete-orphan est utile, mais à priori le cascade DELETE suffit pour garantir qu'il n'y aura pas d'orphelin. D'un point de vue théorique je dirait qu'un CASCADE DELETE équivaut à une aggrégation UML (losange blanc) alors qu'un DELETE OPRHAN correspond à une composition UML (losange noire).
Il existe aussi la valeur all-delete-orphan j'arrive à la même erreur.
J'ai supprimé le all, plus l'erreur, mais ce log qui revient très souvent :
2012/02/03 17:29:32 INFO main (DefaultDeleteEventListener.java:204) handling transient entity in delete processing
Quelqu'un à la traduction ?
Je ne sais pas trop, voir ici pour plus d'infos : http://docs.jboss.org/hibernate/orm/3.6/javadocs/org/hibernate/event/def/Def...
D'où ma question : quelqu'un pourrait dire si et auquel cas, pourquoi, le all est nécessaire ?
le all est souvent nécessaire pour assurer la composition, à la fois sur la sauvegarde et sur la suppression. Si tu l'enlèves, tu n'auras plus de sauvegarde sur les fils lorsque le père sera sauvé. Pour la suppression, le delete-orphan te garantira de ne pas avoir de rejetons sans papa, c'est peut-être dans ces cas qu'il cherche à assurer la suppression des fils même s'ils ne sont pas chargés (transient). J'espère avoir un peu éclairé ta lanterne ;)
Letellier Sylvain letellier@codelutin.com _______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
Le Sun, 5 Feb 2012 21:28:43 +0100, fdesbois <fdesbois@codelutin.com> a écrit :
Le Fri, 3 Feb 2012 17:37:58 +0100, letellier <letellier@codelutin.com> a écrit :
J'ai besoin pour un test de supprimer une volé de donnée avant des les recréer, j'ai donc mis les compos qui vont bien dans mon modèle, je supprime le tout et lors d'une recherche qui n'a rien a voir avec ce que j'ai supprimé plus tôt, je me retrouve avec l'erreur suivante :
org.nuiton.topia.TopiaException: Une erreur est apparue pendant le recherche ([...]) : deleted object would be re-saved by cascade (remove deleted object from associations): [mon joli topiaId]
Vu que le flush (actions en base) se fait sur le select, il cherche à sauver ton entité en cascade. A priori, les éléments supprimés sont toujours attachés à ton objet dans ce contexte, d'où l'erreur.
J'ai regardé dans le mapping et je vois cascade="all,delete-orphan", pour moi le delete-orphan est compris dans le all, non ?
En fait non, le cascade all permet d'effectuer une cascade sur PERSIST, MERGE, DETACH, DELETE. Un cascade DELETE permet lorsque tu supprime ton objet, de supprimer ses enfants qui portent le cascade. Le delete-orphan lui te garanti juste que si un enfant n'a plus de lien pour une raison x ou y avec son père, il sera supprimé. Il doit bien y avoir des cas tordus où le père ne supprime pas les enfants et le delete-orphan est utile, mais à priori le cascade DELETE suffit pour garantir qu'il n'y aura pas d'orphelin.
D'un point de vue théorique je dirait qu'un CASCADE DELETE équivaut à une aggrégation UML (losange blanc) alors qu'un DELETE OPRHAN correspond à une composition UML (losange noire).
Il existe aussi la valeur all-delete-orphan j'arrive à la même erreur.
J'ai supprimé le all, plus l'erreur, mais ce log qui revient très souvent :
2012/02/03 17:29:32 INFO main (DefaultDeleteEventListener.java:204) handling transient entity in delete processing
Quelqu'un à la traduction ?
En fait, je pense que la première erreur provient du Cascade.DELETE lorsque la relation est de type n..m . Dans ce cas là, il cherche à supprimer en cascade un enfant qui peut etre utilisé par une autre entité. Dans une relation de ce type, le cascade.DELETE ne devrait pas être présent, et c'est là qu'intervient le "delete-orphan"/"orphan-removal" : il s'occupera de supprimer un "enfant" des lors que plus aucune entité l'aura dans ses fils. -- Yannick Martel <martel@codelutin.com> Société Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com
participants (3)
-
fdesbois -
letellier -
Yannick Martel