Quelle est exactement la différence dans les deux déclarations suivantes
b est le côté de possession a est le côté de possession en pensant à cela dans "SQL normal", je pense que c'est la même chose que deux tables ayant chacune la clé étrangère de l'autre table. Ce que je ne comprends pas, c'est ce que l'effet de la spécification de quelle entité est le côté de la propriété i.e à l'aide de la propriété 'MappeBy'. Qu'est-ce que cela réelle comme je ne crois pas qu'il y ait un équivalent dans SQL normal.
4 Réponses :
Dans le premier exemple, la table Dans le deuxième exemple Et c'est la différence: -) A va avoir 2 colonnes id et b_id , le b La table va avoir une colonne, ID . Cela fait A le côté de possession.
B est le côté propre. B a deux colonnes, ID et a_id . A va avoir une colonne, ID .
Le côté de la possession est le côté que JPA considère que l'association existe ou non. Supposons que vous alliez avec votre premier exemple. Le côté possède est le côté où il n'y a pas d'attribut mappé. Le côté de possession est donc un, et non B.
Cela signifie que si vous avez une base de données A et A B dans la base de données, et que vous faites p>
A a = em.find(A.class, aId); B b = em.find(B.class, bId); b.setA(a);
Le Spécification JPA 2.0 , section 2.9, écrit:
Les relations peuvent être bidirectionnelles ou unidirectionnelles. Une relation bidirectionnelle a à la fois une partie propre et un côté inverse (non-propriétaire). Une relation unidirectionnelle n'a qu'un côté propre. Le côté de la propriété d'une relation détermine les mises à jour de la relation dans la base de données, comme décrit à la section 3.2.4.
Les règles suivantes s'appliquent aux relations bidirectionnelles:
- Le côté inverse d'une relation bidirectionnelle doit faire référence à son côté propre à l'aide de l'élément
mappé de l'oneoOne ,onetomanan ouPLUSTOMANY Annotation. L'élémentmappé désigne la propriété ou le champ de l'entité qui est le propriétaire de la relation.- Les nombreuses relations bidirectionnelles à une ou plusieurs-un à une ou plusieurs à une fois doivent être le côté de la propriété, d'où l'élément
mappé ne peut pas être spécifié sur leHeuresToone Annotation.- Pour les relations bidirectionnelles d'une-un à une, le côté de possession correspond au côté contenant la clé étrangère correspondante.
- Pour de nombreuses relations bidirectionnelles de chaque côté peut être la partie latérale.
Les parties pertinentes de la section 3.2.4 sont les suivantes:
L'état des entités persistantes est synchronisé dans la base de données à la transaction commettre. Cette synchronisation impliquant une écriture dans la base de données toutes les mises à jour des entités persistantes et de leurs relations telles que spécifiées ci-dessus.
et
Les relations bidirectionnelles entre les entités gérées seront persistées sur la base de références détenues par le côté de la relation. Il incombe à la responsabilité du développeur de conserver les références en mémoire détenues sur le côté de la propriété et ceux qui se sont tenus sur le côté inverse, cohérent les uns avec les autres lorsqu'ils changent. Dans le cas de relations unidirectionnelles un-à-un et une à plusieurs, il est de la responsabilité du développeur d'assurer que la sémantique des relations est respectée.
Il est particulièrement important de s'assurer que les modifications apportées à l'inverse d'une relation entraînent des mises à jour appropriées sur le côté de la propriété, de manière à garantir que les modifications ne sont pas perdues lorsqu'elles sont synchronisées à la base de données.
Comme d'autres ont souligné, vous avez tort de quel côté est le côté de vos exemples. Avec la propriété de la propriété, nous entendons posséder la relation d'un OO Perspecitve, dans la pratique qui finit assez souvent par l'opposé de la manière dont elle est ou sera générée dans la DB si on utilise un RDBM comme fournisseur de persistance.
Dans des circonstances normales, le modèle OO indique clairement que les côtés sont le côté de la propriété. Par exemple, une commande a des lignes de commande. Si nous supprimons une commande, toutes les lignes de commande doivent être supprimées. Si nous supprimons une ligne de commande, la commande a peut-être toujours un droit d'existence. Par conséquent, l'ordre est le côté de la propriété.
Pour un exemple plus concret et excellent, sur les effets de quel côté est le côté intérieur, je me réfère à @JB NIZET Réponse.
Selon la section 2.9 du Spec JPA 2.0 :
Pour les relations bidirectionnelles d'une-un à une, la partie propre correspond au côté qui contient la clé étrangère correspondante.
Mais dans la même section, nous avons aussi:
En outre, cette spécification nécessite également un support pour la suite à des stratégies de cartographie alternatives: [..] la cartographie de relations unidirectionnelles et bidirectionnelles un à un, des relations bidirectionnelles plusieurs à une / une à plusieurs Relations unidirectionnelles plusieurs-un au moyen de la table de jointure mappages.
Un peu plus bas dans la même section qu'il continue avec:
Annotations de mappage supplémentaires (par exemple, mappage de colonne et de table les annotations) peuvent être spécifiées de remplacer ou d'affiner le Mappages par défaut et stratégies de cartographie décrites à la section 2.10. Certaines implémentations utilisent cela pour permettre au FK d'une surnomine birectionnelle d'être dans la table cible.
Pour en lire certaines stratégies de résoudre ce scénario, voir: presque une bonne explication
Je n'ai pas vérifié mais j'espère et j'espère que 2.1 supprimera la première citation. Comme la structure de base de données réelle doit mettre la limite aussi peu que possible sur la manière dont nous pouvons modéliser des données comme entités.
Non, JPA Spécifie que le côté de possession d'un association bidirectionnel de l'onetoone est celui qui contient la clé étrangère. Idem pour bidirectionnelle onetomany.
"Et il peut être utilisé dans une mappage oneoone dans laquelle la clé principale de l'entité de référencement est utilisée comme une clé étrangère de l'entité référencée." Docs.oracle.com/javaee/6/api/javax/ Persistance / ... . La situation juste ne semble pas si souvent.
Et cela ne change rien. Dans ce cas, la colonne Touche principale est la colonne de jointure (d'où le nom primaireKeyJoincolumn) et l'entité contenant cette annotation, et donc la colonne de jointure, est le côté propre. Lisez la réponse de Meriton, contenant cet extrait de la spécification JPA: "Pour les relations bidirectionnelles d'une-un à une, le côté propre correspond à celui contenant la clé étrangère correspondante."
Oui. Je me suis trompé. Je peux le faire dans Eclipselink, et je l'ai totalement manqué n'est pas selon 2.0 Spec final. Le libellé de la spécification me fait un rendez-vous sur la mise en œuvre des spécifications. Je vais mettre à jour ma réponse pour se débarrasser du mensonge. Merci.
Avez-vous vérifié que dans les deux cas, les tables A et B auront un FK les uns aux autres?