Discussion :

[okydo]

bonjour je commence avec hibernate et je me posais une question :

comment peut on crée un type personnelle?
en clair, je veux créer un attribut de type Adresse ( qui comprend plusieurs champs String et autre : residence, numero [String], type de rue [String],rue [String], Ville <many-to-one class="vile">,...).
Si je ne l'utilisai que dans une table je ferai un component je pense que ca sert a ca. mais la j'ai plusieurs objets/tables qui utiliseront ce type d'attribut,(des Personnes, des entreprises, des secrétariast, ...). j'ai plusieurs solutions :
- répéter le "component" dans chaque table
- créer une table adresse avec un lien unidirectionnelle pour ne pas y trouver de clé etrangere.
- autre comme usertype mais la faudrai m'expliqué car dans la doc ils ne sont pas très documenté

Laquelle vous parait la plus aproprié

[Pikwik]

En fonction de ta relation tu fais un many-to-one ou un bag, et une table pour la class Adresse. Cela me parait beacoup plus simple et bien plus logique. Globalement, mieux vaut plusieures tables petite qu'une grosse où tu ajoutes plein de champs.

[okydo]

merci mais j'ai oublier de precisé que je vais avoir plusieurs catalogues donc le problème est que j'aurai 1 table adresse par catalogue sinon j'aurai une seule table avec l'ensemble des adresses de toutes mes applications( 1 application = 1 catalogue)

[manblaizo]

Bonjour,
A mon avis, la première solution (component dans chaque table) est meilleure en termes de performance. Sauf si un objet Adresse possède une identité propre dans ton modèle, je ne vois pas pourquoi tu aurais besoin de définir une table spéciale pour contenir toutes les adresses. Or, si une adresse n'a de l'intérêt que lorsqu'elle appartient a une Personne ou Entreprise, le mieux c'est d'enregistrer les informations d'adresse dans la même table que Personne ou Entreprise. Cela te permet d'avoir une base de données dénormalisée de ce point de vue et d'éviter des "inner join" pour charger l'adresse chaque fois que tu charge une personne ... En tout cas, tu devrais décider en tenant compte des performances et en considérant ce qu'est véritablement l'importance d'une entité adresse par rapport aux autres entités dans ton modèle.
a++

[OButterlin]

D'accord avec manblaizo, la pluspart du temps tu te compliques la vie avec les tables adresses séparées.
Il ne faut pas oublier les contraintes liées, dans le genre :
- une adresse référencée dans une facture émise ne doit plus pouvoir être changée
- 12 rue des Tulipes représente la même adresse que 12 RUE DES TULIPES (et on ne parle même pas des blancs supplémentaires qu'on pourrait trouver)
etc...

Donc, je trouve la solution 1 plus intéressante, au moins tu peux centraliser les contrôles au niveau de cette classe.

Ce n'est qu'un avis...
A+

[okydo]

ok je pense aussi car une table d'Adresse serai assez lourde mais il n'existe pas un racourci pour evité de devoir recopier de compomemt a chaque fois style
<property name="adressePro" type="Adresse" ou class="Adresse"/ > ??

[fr1man]

Est ce que chaque adresse pourrait appartenir à une personne, une entreprise etc en même temps ?
Si c'est le cas, tu vas duppliquer l'information dans n tables.
Qu'en penses-tu ?

[okydo]

oui je pense que chaque table concerné devra avoir une entité adresse propre.
Il n'y aura aucune operation sur l'adresse a part consulter ou modification.
Ce que je cherche simplment c'est si je dois redefinir la classe "Adresse" dans chaque mapping car si je dois modifier l'a classe en ajoutant un champs, faut pas que j'oublie de le faire pour chaque mapping. c'est juste pour des raisons "pratiques".

[fr1man]

J'ai pas tout saisi.
Tu veux dire que ton objet adresse, selon l'objet auquel il sera rattaché, pourrait avoir des champs différents (en plus ou en moins) ?
Si c'est le cas un component parait effectivement être une bonne idée.

Et si tu décides qu'une entreprise ou une personne peut avoir plusieurs adresses, adresse de facturation, de livraison, etc... ce serait pas mal d'avoir une classe (donc une table) propre.

[okydo]

pardon je me suis mal exprimer.

Au contraire je veux que tout mes champs adresse soit fait de la meme maniere.
si ca change pour 1 ca change pour tous. en faite je voudrai que adresse soit consodere (enfin presque considere ) comme un type primitif ou plutot comme une classe JAVA (style Integer, Calendar,...).
d'aprés ce que j'ai pu comprendre c'est de le role de usertype mais je comprend pas comment il fonctionne la doc reste vague a ce sujet.

[OButterlin]

Ce qui te gène, c'est de devoir répéter le bloc de définition pour chaque table contenant une adresse dans le fichier de mapping...
Je ne vois pas de moyen pour "by-passer" cette étape (encore que ce soit un copier/coller à chaque fois...)

[fr1man]

Dans ce cas, je ferais une classe Adresse correspondant à une table Adresse, même si ça va à l'encontre de ce que t'ont proposé OButterlin et manblaizo.

[OButterlin]

Dans ce cas, je ferais une classe Adresse correspondant à une table Adresse, même si ça va à l'encontre de ce que t'ont proposé OButterlin et manblaizo.

C'est effectivement une possibilité... avec une relation 1 pour 1...

L'avantage, tu centralises la gestion de l'adresse.
L'inconvénient, tu fais 2 lectures par entité contenant une adresse.

[okydo]

j'ai peut etre trouver une piste le compositeUserType mais bon faut s'accroché:
http://www.hibernate.org/178.html
ca repond a mes beoin mais faut voir si ca va pas demandé plus de travail qu'autre chose .
je vais quand meme regarder de plus prés part curiosité

[OButterlin]

C'est plutôt pour agglomérer plusieurs colonnes en 1 propriété... et comme tu peux le constater dans l'exemple, tu as aussi le mapping à répéter...

[manblaizo]

j'ai peut etre trouver une piste le compositeUserType mais bon faut s'accroché:
http://www.hibernate.org/178.html
ca repond a mes beoin mais faut voir si ca va pas demandé plus de travail qu'autre chose .
je vais quand meme regarder de plus prés part curiosité

Non, je ne pense pas que tu aies besoin de CompositeUserType pour ça, un component suffirait. Ton problème c'est d'éviter de devoir répéter les modifications dans chaque fichier de mapping quand la classe Adresse est modifiée. Tu as deux solutions :
- Utiliser les annotations, et là tu n'auras qu'à déclarer @Embeded devant la propriété "adresse" dans chaque classe où tu l'utilise et le reste est pris en charge automatiquement.
- Si tu n'utilises pas encore les annotations, alors tu as Xdoclet qui te pemet de générer les fichiers de mapping et de ne pas avoir à répéter des opérations dans différents fichiers.
Sinon, je ne vois pas comment tu pourrais éviter de répéter les éléments <component> dans chaque mapping, et je suis d'accord avec toi que c'est très "error-prone" ...
a++

[okydo]

Oky merci

je crois que jvais suivre ton conseil manblaizo, je vais utilise le component.
et Crtl+c crtl+v est ton ami c'est bien connu. en esperant ne pas le regreter lol.