Discussion :

[drissoi]

Bonjour,
J'aimerai bien comprendre la différence entre les ralations JPA entre deux entités, pourquoi on utilise t'on un manytoone au lieu de onetoMany ?
exemple : une personnes a plusieurs téléphones (de differentes natures (bureau, fixe, mobile ...)) , dans ce cas on pourrait utiliser un OneToMany c'est a dire, une personne a plusieurs téléphones, la classe Personne porte la relation sur un champ Liste de telephone , ou bien choisir la relation ManyToOne,plusieurs téléphones cooresspondent une personne., la classe Telephone porte la relation vers un objet Personne.

Pourquoi on parle de relation réciproque et de relation directe, et pourquoi on choisit tjs ManyToOne ??

Merci.

[OButterlin]

C'est l'usage qui fait la différence.
Si tu as un seul père, tu utilises une ManyToOne.
Si tu as une liste de fils, c'est une OneToMany
J'ai du mal à comprendre ta problématique, je me demande si ce n'est pas la combinaison des 2 qui te perturbe...

Très souvent, l'objet maître à une relation vers ses fils de type OneToMany ET les fils ont une relation vers le père en ManyToOne.
L'intérêt est lié au mode de fonctionnement des ORM dans le cas d'une création, avec des tables ayant des clés primaires auto-générées.

En reprenant ton exemple, tu as un objet Personne qui référence une liste de numéros de téléphone représentées par un objet List<NumeroTelephone>, l'objet NumeroTelephone ayant un lien vers son père puisque la relation est unique entre la personne et le numéro.

En création, tu vas persister l'objet Personne uniquement (attribut cascade sur la liste de numéros) et l'ORM va se charger de persister les numéros associés.
A ce moment, on n'a pas d'ID pour le père (Personne), si on n'avait pas mis l'instance de l'objet Personne dans NumeroTelephone, il serait impossible d'enregistrer les 2 dans le même cycle. On devrait persister la personne seule d'abord, puis faire une bouche sur les numéros pour associer l'ID de la personne au NumeroTelephone avant de persister le numéro.

Si tu ne comprends pas plus, n'hésite pas à poser d'autres questions, j'ai des doutes sur la clarté de mon explication...

[drissoi]

Bonjour, ravi de ta reponse,

Si tu as un seul père, tu utilises une ManyToOne.
Si tu as une liste de fils, c'est une OneToMany

Pour moi les deux sont équivalents car réciproque dans le sens. mais il est plus logique de dire un père a plusieurs fils.

A ce moment, on n'a pas d'ID pour le père (Personne), si on n'avait pas mis l'instance de l'objet Personne dans NumeroTelephone, il serait impossible d'enregistrer les 2 dans le même cycle. On devrait persister la personne seule d'abord, puis faire une bouche sur les numéros pour associer l'ID de la personne au NumeroTelephone avant de persister le numéro.

Donc si je comprends bien l'utilisation d'une relation se fait par rapport aux operations que le SGBD va percuter.

en terme de logique il est plus cohérant de dire qu'une personne a plusieurs numeros de téléphones , donc utiliser ici le oneToMany , que de dire plusieurs téléphones correspondent à une personne, donc utiliser la manyToOne ici.
Merci.

[OButterlin]

Sauf que si tu te places du point de vue de l'ORM, il lui faut bien "quelque chose" pour qu'il puisse récupérer la clé étrangère quand il persiste les fils...
On est bien d'accord qu'en base de données, ta table "Personne" n'a aucun attribut ou clé se référent à un numéro de téléphone alors que la table "NumeroTelephone" à un ID de Personne (avec bien souvent une contrainte d'intégrité référentielle et un delete cascade).
Si tu n'avais qu'un Integer (typique du cas d'une clé primaire incrémentale) dans ton mapping, il serait impossible à l'ORM de savoir à quoi il se rapporte.
Alors qu'en incluant l'objet "Personne" auquel il se rapporte, il peut récupérer l'ID de la personne à affecter à la clé étrangère de "NumeroTelephone".
Techniquement, l'ORM fait :
1) persister l'objet Personne
2) récupère l'ID généré par la base de données et le place dans l'objet "Personne"
3) persiste les numéros en récupérant l'ID du père (la personne)

Code :

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

1
2
3
4
5
 
Personne personne = new Personne();
personne.set...
...
personne.getNumeros().add(new NumeroTelephone(personne, numero));

Là, tu vois qu'une fois que l'ORM aura récupéré l'ID généré et l'aura placé dans l'instance "personne" et qu'il s'occupera de persister les numéros, il accédera directement à la clé primaire de "Personne" par l'instance qui est associée à l'instance de "NumeroTelephone" (c'est la même adresse, donc l'étape 2 aura rendu visible la clé de personne)

[drissoi]

Entierement d'accord avec toi , mais ta réponse la encore ne traite pas ma question ?
en terme de logique il est plus cohérant de dire qu'une personne a plusieurs numeros de téléphones , donc utiliser ici le oneToMany , que de dire plusieurs téléphones correspondent à une personne, donc utiliser la manyToOne ici.

Comment on choisit l'un ou l'autre ? et pourquoi on priviligie toujours la relation manytoOne qui est directe ???

Merci beaucoup.

[OButterlin]

Si tu veux faire totalement abstraction des contraintes liées à la techno, tu peux voir les choses comme ceci :
Qui est propriétaire de la relation et quelle est la cardinalité ?

Dans ton exemple, c'est bien la personne qui est propriétaire de n numéro, donc, l'objet Personne contient une liste de numéro avec une relation OneToMany

Dans d'autres cas, un objet est propriétaire d'une information unique (Sexe par exemple pour rester dans le contexte d'une personne) et la référencera par une relation ManyToOne (si bien sûr on voulais utiliser une table pour matérialiser les valeurs de sexe)

[drissoi]

Dans ton exemple, c'est bien la personne qui est propriétaire de n numéro, donc, l'objet Personne contient une liste de numéro avec une relation OneToMany

pourquoi alors dans certains cas on priviligie la relation manyToOne qui va être porte sur le numero. Pour ce meme cas on utilise la relation manyToOne.
Quel est l'avantage à utiliser la relation manyToOne ici pour ce meme exemple ?

Dans d'autres cas, un objet est propriétaire d'une information unique (Sexe par exemple pour rester dans le contexte d'une personne) et la référencera par une relation ManyToOne (si bien sûr on voulais utiliser une table pour matérialiser les valeurs de sexe)

La personne est toujours propiètaire de son Sexe donc la on peut toujours mettre la relation dans personne. (pourquoi faire l'inverse ?? )

Je ne comprends pas , car pour moi ton explication consiste a réfléchir a l'envers, c'est un peu déroutant au final.

Merci beaucoup.