Composition et cascade
Bonjour, Dans la PJ, les relations utilisent des compositions, mais les cascades générées sont: cascade="delete" C'est typiquement le boulot d'hibernate de sauvegarder ces instances, et je ne devrais pas à avoir à forcer la sauvegarde manuellement. Mais est-ce généralisable à toutes les compositions ? Cordialement, Eric Chatellier -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 14/05/2014 17:22, Eric Chatellier a écrit :
Mais est-ce généralisable à toutes les compositions ?
À la base, j'aurai été plutôt contre la demande d'Éric, mais je suis tombé sur un autre exemple (dans Lima). Soit le modèle en PJ, voici ce qui est généré comme mapping : <bag name="financialPeriod" lazy="true" cascade="all,delete-orphan" node="financialPeriod"> <key column="fiscalPeriod"/> <one-to-many class="org.chorem.lima.entity.FinancialPeriodImpl" node="topiaId"/> </bag> Il y a bien le cascade="all,...". Et ça se vérifie dans le code appelant (sauf mauvaise interprétation de ma part) : // instanciation de la liste (pas de persistence) List<FinancialPeriod> financialPeriods = accountingRules.createFiscalPeriodRules(fiscalPeriod); // liste contenant 3 éléments // ajout des 3 objets à la liste de l'objet de base : fiscalPeriod.addAllFinancialPeriod(financialPeriods); result = fiscalPeriodTopiaDao.create(fiscalPeriod); // Ici, les 4 objets ont été créés en base Donc en gros, si je comprends bien : A -1-composite----------N-> B : cascade all,delete-orphan A -1-composite----------1-> B : cascade delete Il faut pousser un peu plus la réfléxion, mais (dans l'immédiat) je trouve que ce n'est pas cohérent et donc je suis d'accord avec la demande d'Éric. Arnaud
Le 20/05/2014 16:47, Arnaud Thimel a écrit :
Il faut pousser un peu plus la réfléxion, mais (dans l'immédiat) je trouve que ce n'est pas cohérent et donc je suis d'accord avec la demande d'Éric.
Pareil. Mon point de vue il y a quelques temps était celui-là A -1-composite----------N-> B : cascade all A -1-composite----------1-> B : cascade all A -1-agrég--------------N-> B : cascade all, delete-orphan A -1-agrég--------------1-> B : cascade all, delete-orphan le delete-orphan traduisant en fait que c'est pas vraiment un cascade-all (car on ne cascade pas les delete). Le composite signifierait alors que le B appartiennent exclusivement aux A et suivent le même cycle de vie. Exemple Pollen : Sondage -----n-> Vote. Quand on sauvegarde le sondage, on sauvegarde les votes ; quand on supprime le sondage, on supprime les votes. Idem pour l'agrégation, la nuance est que les instances de B peuvent être partagées entre plusieurs A. Il ne faut donc pas forcément supprimer en cascade vu qu'il ne faut pas risquer du supprimer un B utilisé par un autre A. Par contre, les B n'ont plus de raison d'exister s'il n'y a plus aucun A donc on les supprime. Ça me paraît toujours être le bon raisonnement mais plus ça va, plus j'ai des doutes sur la réelle signification de la composition et de l'agrégation donc ce ne sont peut-être pas les formalismes à utiliser : le raisonnement reste valide mais peut-être utiliser autre chose pour signaler ces relations. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 20/05/2014 17:20, Brendan Le Ny a écrit :
j'ai des doutes sur la réelle signification de la composition et de l'agrégation
Wikipedia confirme ce que je dis pour la composition mais infirme par l'agrégation. Il est possible qu'un B continue à exister même si aucun A ne l'utilise. http://en.wikipedia.org/wiki/Object_composition -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
participants (3)
-
Arnaud Thimel -
Brendan Le Ny -
Eric Chatellier