Consolider un peu la gestion des relations many-2-many
Salut, Je viens de corriger un bug de génération de mapping et du coups je tombe sur un code bien mystérieux concernant la gestion de l'inverse sur les relations many-2-many : // On ne met le inverse="true" uniquement pour un seul coté de la relation. // Dans le cas contraire, les modifications dans la relation ne seront // pas sauvegardées. Ceci n'est vrai que si les deux coté sont navigable boolean isInverse = attr.isNavigable() && attr.getReverseAttribute().isNavigable(); //isInverse |= !Util.isFirstAttribute(attr); //isInverse = false; // 20070117 poussin: pour du many, jamais de inverse // Modification FD-2010-04-01 : // Le tagvalue "inverse" permet de spécifier qui possède le // inverse="true". Il est impératif de l'utiliser sur les deux // extrémités pour ne pas avoir de surprise. String inverseValue = TopiaGeneratorUtil.getInverseTagValue(attr); if (StringUtils.isNotEmpty(inverseValue)) { isInverse &= Boolean.parseBoolean(inverseValue); // Si aucun tagvalue n'est défini, le choix est arbitraire : le // premier attribut dans l'ordre alphabétique sera choisi pour porter le // inverse="true" } else { isInverse &= GeneratorUtil.isFirstAttribute(attr); } Moi je vous avoue ne rien y comprendre dans cette gestion stricte (inverse sur les deux targets avec un boolean a True ou a False) ou bien choisir celui de plus petit ordre alphabétique ? Euh... Ca sert à quoi ? Je serais vraiment d'avis qu'on revoit cette gestion regrettable. Pour moi on ne doit pas laisser le second mode qui rend la gestion de la relation dépendante du nom des relations (pfff... d'où ça sort cette blague :)). Après laisser deux tag-values (une sur chaque extrémité) ne m'emballe guère car une seule tag value sur le maître me parait suffisant. Pourquoi ne pas plutôt utiliser une nouvelle tagValue (car inverse ça veut pas dire grand chose en fait en terme de modélisation...) qui indique qui est le propriétaire de la relation, on pourrait alors en déduire l'attribute inverse nécessaire pour le mapping hibernate. Si la relation n'est pas présente, on déclanche une exception histoire d'être safe. Pour le nom de la nouvelle tag value, je sais pas trop vu que j'utilise jamais ce genre de relation (j'en ai de la chance :)) : - relationOwner - relationMaster Merci pour vos réponses constructives :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 12/02/2011 10:59, chemit a écrit :
Moi je vous avoue ne rien y comprendre dans cette gestion stricte (inverse sur les deux targets avec un boolean a True ou a False) ou bien choisir celui de plus petit ordre alphabétique ?
Euh... Ca sert à quoi ?
Simplement à faire un choix reproductible des deux côtés de la relation lors de la génération.
Je serais vraiment d'avis qu'on revoit cette gestion regrettable.
Oui, il serait temps de clarifier ça.
Pour moi on ne doit pas laisser le second mode qui rend la gestion de la relation dépendante du nom des relations (pfff... d'où ça sort cette blague :)).
Pfff ? Sans ajouter de tag value supplémentaire, c'est à peu près la seule façon d'assurer que les deux côtés ne vont pas tout les deux se déclarer maitre (ou esclave) de la relation.
Après laisser deux tag-values (une sur chaque extrémité) ne m'emballe guère car une seule tag value sur le maître me parait suffisant.
Pourquoi ne pas plutôt utiliser une nouvelle tagValue (car inverse ça veut pas dire grand chose en fait en terme de modélisation...) qui indique qui est le propriétaire de la relation, on pourrait alors en déduire l'attribute inverse nécessaire pour le mapping hibernate.
Si la relation n'est pas présente, on déclanche une exception histoire d'être safe.
Le coup de l'exception, je ne sais pas trop quoi en penser. Si l'utilisateur n'a pas besoin de définir un maitre, pourquoi le forcer à le faire ? On peut faire un choix arbitraire.
Pour le nom de la nouvelle tag value, je sais pas trop vu que j'utilise jamais ce genre de relation (j'en ai de la chance :)) : - relationOwner - relationMaster
Merci pour vos réponses constructives :)
Mais de rien. Arnaud.
On Fri, 25 Feb 2011 14:38:50 +0100 Arnaud Thimel <thimel@codelutin.com> wrote:
Le 12/02/2011 10:59, chemit a écrit :
Moi je vous avoue ne rien y comprendre dans cette gestion stricte (inverse sur les deux targets avec un boolean a True ou a False) ou bien choisir celui de plus petit ordre alphabétique ?
Euh... Ca sert à quoi ?
Simplement à faire un choix reproductible des deux côtés de la relation lors de la génération.
Je serais vraiment d'avis qu'on revoit cette gestion regrettable.
Oui, il serait temps de clarifier ça.
Pour moi on ne doit pas laisser le second mode qui rend la gestion de la relation dépendante du nom des relations (pfff... d'où ça sort cette blague :)).
Pfff ? Sans ajouter de tag value supplémentaire, c'est à peu près la seule façon d'assurer que les deux côtés ne vont pas tout les deux se déclarer maitre (ou esclave) de la relation. oui Pfff, mettre deux déclarations de tag-values pour avoir une info ça sort d'où ? et répète bien pfff (ou je devrais plutôt dire berk.).
Après laisser deux tag-values (une sur chaque extrémité) ne m'emballe guère car une seule tag value sur le maître me parait suffisant.
Pourquoi ne pas plutôt utiliser une nouvelle tagValue (car inverse ça veut pas dire grand chose en fait en terme de modélisation...) qui indique qui est le propriétaire de la relation, on pourrait alors en déduire l'attribute inverse nécessaire pour le mapping hibernate.
Si la relation n'est pas présente, on déclanche une exception histoire d'être safe.
Le coup de l'exception, je ne sais pas trop quoi en penser. Si l'utilisateur n'a pas besoin de définir un maitre, pourquoi le forcer à le faire ? On peut faire un choix arbitraire.
le choix arbitraire où si tu changes le nom d'une des deux entités et que la gestions de tes entités est différente en base me paraît trop laxiste. après on peut toujours avoir un mode au niveau du plugin 'laxiste' :)
Pour le nom de la nouvelle tag value, je sais pas trop vu que j'utilise jamais ce genre de relation (j'en ai de la chance :)) : - relationOwner - relationMaster
Merci pour vos réponses constructives :)
Mais de rien.
ah si j'insiste car tu es bien le seul à avoir répondu alors que d'autre aussi on mit en place ce système ;)
Arnaud.
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
le choix arbitraire où si tu changes le nom d'une des deux entités et que la gestions de tes entités est différente en base me paraît trop laxiste.
après on peut toujours avoir un mode au niveau du plugin 'laxiste' :)
On peut laisser l'utilisateur faire son truc sans tagValue dans un premier temps, et laisser le mode "laxiste" puisque ça marche. S'il renomme son entité, il sera toujours temps pour lui d'ajouter la tagValue qui va bien pour ne pas avoir à renommer sa table. Après, les mecs qui veulent être safe (ou "la bonne pratique") sont libres de poser la tagValue systématiquement. J'suis plutôt tendance strict-mode, à la Tony, mais faut pas que ça emmerde le mec de trop. J'en dis pas plus parce que je maitrise pas bien la notion d'inverse. -- Brendan Le Ny Code Lutin
participants (3)
-
Arnaud Thimel -
Brendan Le Ny -
chemit