Les différences de @One-to-Many relation et @ElementCollection

Bonjour les amis :)

Quelles sont les différences de @One-to-Many relation et @ElementCollection ?

Merci

Bonjour,

Je ne connaissais pas ce nouveau concept, mais je viens de fouiller un peu et fait quelques tests et je trouve cela super intéressant. En fait tu peux mapper une entité avec une liste d'objets basiques ou même primitifs.
Donc pour répondre à ta question le @ElementCollection est un ensemble beaucoup plus grand que le @OneToMany, pendant que le @OneToMany se limite aux entités (ou aux enregistrements), le @ElementCollection peut se mapper sur tout ou partie d'une table. C'est très bien expliqué dans ce wiki.

Il y a une différence de taille au niveau de la "cascade".
Pour ElementCollection, c'est systématiquement persisté avec l'entity porteur.
Avec la relation @OneToMany, on peut persister de manière plus fine...

Sinon, ça semble très intéressant dans certains cas, je ne connaissais pas...

En regardant le wiki indiquée par DevServlet, j'ai du mal à voir la différence avec ce code que je faisais il y a encore quelques temps qd j'utilisais les fichiers hbm pour le mapping de mes entités :

Code:

---

1 2 3 4 5 6

<list name="answers" table="answersdb"> <key column="qid"></key> <index column="type"></index> <element column="answer" type="string"></element> </list>

---

avec le code mentionné avec le wiki

Code:

---

1 2 3 4 5 6 7

<element-collection nam <column name="PHONE_NUMBER"/> <collection-table name="PHONE"> <join-column name="OWNER_ID"/> </collection-table> </element-collection>

---

merci d'éclairer ma lanterne;)

Bonjour,
@ElementCollection

L'annotation ElementCollection offre des facilités pour la persistence des listes de types primitifs ou de types de base de Java comme Integer ou String.
Auparavant, pour persister une liste de String par exemple, il était nécessaire de persister sous forme de Blob un objet sérialisé contenant les valeurs à enregistrer, cet objet pouvant être une ArrayList ou un HashSet par exemple . Le "probleme" venant du fait que le type String n'étant pas une entité JPA, il ne pouvait être mappé avec un traditionnel @ManyToOne ou @ManyToMany. Un autre contournement possible était de créer une entité JPA comprenant uniquement le String à persister entant qu'attribut et éventuellement une clé technique. Créer une telle table parait logique si on analyse le problème d'un point de vue relationnel, par contre d'un point de vue objet il est dommage d'avoir à s'encombrer d'une telle classe.
Heureusement avec JPA 2 et l'annotation ElementCollection , ce genre de mapping devient beaucoup plus naturel.

Cette annotation s'utilise comme ceci :

Code:

---

1 2 3 4

@ElementCollection @CollectionTable(name = "nom") @Column(name = "value") List<String> noms;

---

En utilisant cette annotation, une table comprenant une clé technique + la valeur à enregistrer pour chaque String sera créee automatiquement et utilisée de manière transparente. JPA fait donc bien son travail : s'occuper des problématiques de stockage des données dans le modèle relationnel, en laissant le développeur créer un modèle cohérent d'un point de vue objet.

L'annotation Column permet de spécifier le nom de la colonne qui contiendra les valeurs (des String dans notre exemple) à persister.
Enfin, l'annotation CollectionTable permet de spécifier le nom de la table à générer pour stocker ces valeurs.

Les annotation Column et CollectionTable sont optionnelles, si elles ne sont pas présentes des valeurs par défauts seront utilisées pour les noms de tables et de colonnes.