Discussion :

[vinceLeBarbare]

Bonjour,
j'ai deux classes que je souhaite mapper pour hibernate a l'aide de XDoclet, c'est a dire mettre les tags pour créer le fichier de mapping automatiquement, qui me posent problème.

En effet, la classe SchemaTherapeutique extends la classe catégorie.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Category {
private long id_category;
private String libelle;
private String libelle_c;
....
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public class SchemaTherapeutique extends Category {
private long id_schema_therapeutique;
private List composant;
....
}

Je n'arrive pas à trouver quel stratégie je me rattache (une classe par classe concrète, une classe par sous-classe...).
Pouvez vous m'aider à générer mon fichier de mapping.

Merci

[BizuR]

La détermination de la stratégie est fonction de la base de données que tu veux obtenir :

Une mm table pour les deux ==> table per Hierarchy avec discriminant
Une table pour chaque classe contrete==> table per ConcreteClass
Une table pour chacun ==> table per SubClass

Je déconseille la seconde qui est sujette à certaines limitations dues au polymorphisme implicite ou bien au probleme des "noms de colonnes identique"

Décris nous déjà le modèle que tu veux utiliser puis nous te guiderons vers le mapping approprié.

PS: Pour plus de détail sur les stratégies d'héritage, il existe des posts les détaillant et expliquant leurs avantages et inconvénients.

[vinceLeBarbare]

Ben au niveau de la base de données, je voudrais obtenir deux tables : une category avec un identifiant et un libellé et la table schema_therapeutique qui a un identifiant, une liste de composant et l'identifiant de la category dont elle découle.

j'espere avoir ete assez clair

[BizuR]

Ah, tout ca dans le cadre d'un héritage. Malheureusement, ton cas ne rentre pas dans les 3 stratégies classiques d'héritage :

- Une table pour tous : Tu mets tous les attributs dans une unique table et ceux des classes filles en not-null = "false". En plus tu y ajoutes un champ discriminant permettant de dissocier tel ou tel objet (par une chaine de caractere, un entier ou bien un char)

- Une table par classe : Tu auras deux tables ici, chacune avec ses propres attributs. Pour savoir quel est le type de l'objet, tu utilises les mêmes identifiants.

- une table par classe concrete : Une seule table dans ton cas qui regroupe tous les attributs et si jamlais tu as une seconde classe fille, tu refais une autre table avec tous les attributs (dont ceux de la classe mère à chaque fois).

Je pense qu'ici, ton cas se rapproche le plus du second. Il faut uniquement que tu utilises le même identifiant pour tes tables, ca donnerait cette architecture de table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CATEGORY(identifiant,libelle)
SCHEMA_THERAPEUTIQUE(identifiant, liste_composants), 
     FK = identifiant, references CATEGORY(identifiant)

En gros ici une relation 1..1 entre les deux tables

Questions :
-liste_composant est une chaine de caractere ou bien autre chose ?!?
-ce que tu me décrivait toi avant ressemblait plus à une relation avec clé étrangère qu'à un héritage. Sémantiquement, cette relation tient donc d'un 1..N ou d'un héritage ?!?

[vinceLeBarbare]

liste_composant, c'est autre chose : liste d'objet de type Composant
et j'ai mis mon identifiant de catégorie comme une clé externe, ca me simplifie le travail

merci

[BizuR]

identifiant de categorie en clé externe ?!? Euh, la clé étrangère FK dont je parlais portait sur l'identifiant de SCHEMA_THERAPEUTIQUE. J'espere que c'est bien ainsi que tu l'avais compris... car de mon coté j'aurai ainsi plutot parler de clé externe pour SCHEMA_THERAPEUTIQUE . C'est surtout CATEGORY qui centralisera tous les identifiants de chaque fille. Et chacune ira ensuite spécialisé ses attributs dans sa table fille respective