Discussion :

[emilie_caroline]

Je n'ai pas vraiment vu tous les post alors si ma question a déjà été posé, merci de me redirigé.

Ma question est plutot un conseil.

J'ai une classe A qui a deux ensembles (ens 1 et ens 2) de la classe B. un élément de l'ens 1 ne peut appartenir l'ens 2 et inversement.
Au niveau du modele relationnel j'ai deux tables.
Comment mapperiez vous ca vous dans ce cas?

[xv-mnt]

Tu pourrais sous-classer ta classe B en 2 sous-classes B1 et B2, pour l'ensemble 1 et l'ensemble 2 respectivement, avec une stratégie d'héritage de 1 table par hiérarchie.
Une contrainte, ajouter une colonne supplémentaire pour faire la discrimination entre les 2 types de classes.

[emilie_caroline]

effectivement j'y avais pensé. Mais je voudrais éviter !!! J'aimerais garder le modèle objet tel que je l'ai décris. J'aimerais que la solution vienne du mapping (par contre je me doute qu'il va falloir rajouter une colonne dans ma table B pour les différencier)

[fr1man]

Tu pourrais rajouter une colonne dans ta table B pour identifier tes ensembles.
Dans ton mapping de A, dans la définition de tes Set, tu pourrais rajouter l'attribut "where" afin de récupérer les objets de B en fonction de la nouvelle propriété.

[manblaizo]

Tu pourrais sous-classer ta classe B en 2 sous-classes B1 et B2, pour l'ensemble 1 et l'ensemble 2 respectivement, avec une stratégie d'héritage de 1 table par hiérarchie.
Une contrainte, ajouter une colonne supplémentaire pour faire la discrimination entre les 2 types de classes.

Je pencherais aussi pour une solution d'héritage de la classe B, mais par contre, pour la stratégie de mapping ce serait 1 table par sous-classe, sans colonne supplémentaire pour la discrimination. En principe, en l'absence de discriminator, Hibernate outilise la réflexion pour assurer le mapping dans ce cas. Pour définir les deux ensembles, la classe A aurait deux relations one-to-many directement avec chacune des sous-classes et non avec la classe de base.

[xv-mnt]

effectivement j'y avais pensé. Mais je voudrais éviter !!! J'aimerais garder le modèle objet tel que je l'ai décris.

Question : pourquoi veux-tu éviter de modifier le modele objet en sous-classant B avec B1 et B2 ?

Pour moi, il me semble plus contraignant de modifier les tables, car le schéma peut parfois nous être imposé de l'extérieur (le modèle est existant et figé par exemple car déjà en prod.).

De plus, rien ne t'empeche de travailler ensuite directement avec la superclasse.

[emilie_caroline]

Tout d'abord merci pour vos réponses pertinentes!

Si j'utilise une hiérarchie au niveau objet, je suis obligé de changer également mon modele relationnel (2 tables pas sous-classe), car la solution une table par hiérarchie n'est pas satisfaisant à mon gout et ne permet pas vraiment le polymorphisme (voir livre hibernate 3)
De ce fait la clause "where" me parait une bonne idée. Je ne connais pas vraiment comment ca marche (j'en ai une idée) il faudrait que je renseigne.

[xv-mnt]

La question n'est pas de faire du polymorphisme pour faire du polymorphisme, mais de répondre (élégamment à mon goût) à une problématique posée.
De plus, dans certains cas, avoir une seule table par hiérarchie permet d'éviter les requêtes de jointures dans certains cas limites : gros volumes + beaucoup d'attributs en commun.
De toute manière, tu as qd même pas mal de solutions à ton pb

@+

[manblaizo]

Si j'utilise une hiérarchie au niveau objet, je suis obligé de changer également mon modele relationnel (2 tables pas sous-classe), car la solution une table par hiérarchie n'est pas satisfaisant à mon gout et ne permet pas vraiment le polymorphisme (voir livre hibernate 3)

Quelques questions s'imposent :
1. Le schéma de la base de données t'es imposé ou tu en as le contrôle et donc la possibilité de modifier les tables ?
2. Les deux fameuses tables contiennent-elles des données exactement du même type ou y a-t-il des champs qui diffèrent ?
3. Peux-tu poster une partie du code de la classe A et ses références à la classe B (histoire de voir s'il y a moyen de faire autrement) ?