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) ?

[emilie_caroline]

Alors
Tout d'abord j'ai effectivement le controle de la base de données. Toutefois l'application web qui se sert de la base est aujourd'hui en production. Il est donc délicat de détruire ou de faire migrer des données d'une table à une autre -> rajouter une colonne ne pose aucun problème mais d'autre changements seraient délicat.

Ensuite
Je ne comprends pas tout à fait des deux tables dont tu parles mais voilà :
la classe A représente un groupe et la classe B des personnes.
Les deux associations dont je parle représente
-l'ensemble des membres de ce groupes
-l'ensemble des administrateurs de ce groupes

La classe A et B (à fortiori les tables correpondantes) n'ont rien à voir.
De plus les membres des groupes et admin sont exactements les mêmes objets (appratiennent à une seule table).

enfin je ne peux poster de code

J'espère qu'il s'agit des réponses que tu voulais.

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

Le problème vient également du fait qu'on ne peut utiliser la variable null.

[manblaizo]

Alors
Tout d'abord j'ai effectivement le controle de la base de données. Toutefois l'application web qui se sert de la base est aujourd'hui en production. Il est donc délicat de détruire ou de faire migrer des données d'une table à une autre -> rajouter une colonne ne pose aucun problème mais d'autre changements seraient délicat.

C'est vrai que si la base de données est déjà en production, tu n'as plus beaucoup de choix, quoique il y a toujours moyen de refactoriser si ta couche présentation de l'application web n'est pas fortement couplée à la base de données. Mais, comme tu le dis, la migration des données représenterait peut-être un autre problème...

Ensuite
Je ne comprends pas tout à fait des deux tables dont tu parles mais voilà :
la classe A représente un groupe et la classe B des personnes.
Les deux associations dont je parle représente
-l'ensemble des membres de ce groupes
-l'ensemble des administrateurs de ce groupes

La classe A et B (à fortiori les tables correpondantes) n'ont rien à voir.
De plus les membres des groupes et admin sont exactements les mêmes objets (appratiennent à une seule table).

Alors, si j'ai bien compris, il y aurait deux tables, l'une correspondant aux groupes (classe A) et l'autre aux personnes (classe B). Et la table des personnes contient aussi bien des membres simples d'un groupe que les administrateurs de ce groupe; right ?
Dans ce cas, la table de personnes comprend surement un champ pour distinguer un administrateur d'un membre simple ? Et là, je me demande si une simple requête HQL sur classe A, avec le paramètre nécessaire, ne suffirait pas, plutôt que d'avoir deux collections différentes dans la classe.
Enfin, je sais pas si j'ai bien compris ta problématique...

[emilie_caroline]

Oui je crois que tu as bien compris.
Le principe est surtout de faire en sorte que le mapping me permette de récupérer les deux ensemble grace à un A.getMembreDeA et B.getAdminsitrateur.

Aujourd'hui mon mapping definit les deux ensembles mais comme rien ne permet de faire la différence entre les membres et les admins A.getMembreDeA et A.getAdminsitrateur me retournent tous les deux l'ensembles des persons (les membres et les admins)

Voilà, j'ai eu suffisemment de réponses pour faire quelquechose de correct. Toutefois si vous avez encore quelques idées (voire des idées de génie) ....