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.