Quand utiliser inverse = false sur les relations NHibernate / Hibernate OneToMany?

Question

Je suis en train de se familiariser avec l'attribut inverse de mise en veille prolongée, et il semble être juste une de ces choses qui est difficile sur le plan conceptuel.

L'essentiel que je reçois est que lorsque vous avez une entité mère (par exemple parent) qui a une collection d'objets d'enfant à l'aide d'un one-to-many mapping, réglage inverse = true sur la cartographie dit à Hibernate que «l'autre côté (l'enfant) a la responsabilité de se mettre à jour pour maintenir la référence clé étrangère dans sa table.

Faire cela semble avoir 2 avantages en ce qui concerne l'ajout d'enfants à la collecte dans votre code, puis sauver le parent (avec cascade tous ensemble):

Cela semble tout à donner un sens à ce jour. Ce que je ne comprends pas est le suivant:? À quel moment vous pas veulent utiliser inverse = true sur un à-plusieurs

Answer 1

Comme Matthieu dit, le seul cas où vous ne voudriez pas définir inverse = true est là où il n'a pas de sens pour l'enfant d'être responsable de se mettre à jour, comme dans le cas où l'enfant n'a pas connaissance de son parent.

permet d'essayer un monde réel, et non par exemple du tout arrangé:

<class name="SpyMaster" table="SpyMaster" lazy="true">
  <id name="Id">
    <generator class="identity"/>
  </id>
  <property name="Name"/>
  <set name="Spies" table="Spy" cascade="save-update">
    <key column="SpyMasterId"/>
    <one-to-many class="Spy"/>
  </set>
</class>

<class name="Spy" table="Spy" lazy="true">
  <id name="Id">
    <generator class="identity"/>
  </id>
  <property name="Name"/>
</class>

peuvent avoir des espions maîtres espions, mais des espions savent jamais qui leur est spymaster, parce que nous n'avons pas inclus la relation many-to-one dans la classe d'espionnage. De plus (idéalement) un espion peut tourner voyous et donc n'a pas besoin d'être associé à un spymaster. Nous pouvons créer des entités comme suit:

var sm = new SpyMaster
{
    Name = "Head of Operation Treadstone"
};
sm.Spies.Add(new Spy
{
    Name = "Bourne",
    //SpyMaster = sm // Can't do this
});
session.Save(sm);

Dans ce cas, vous définissez la colonne FK être annulable parce que l'acte de sauver sm insérerait dans la table Spymaster et la table Spy, et seulement après cela serait-il mettre à jour alors la table Spy pour régler le FK. Dans ce cas, si nous devions mettre inverse = true, le FK serait jamais mis à jour.

Answer 2

En dépit de la réponse acceptée haute voté, j'ai une autre réponse à cette question.

Considérons un diagramme de classes avec ces relations:

Parent => list of Items
Item => Parent

Personne jamais dit que l'article => relation parent est redondant au parent => relation Items. Un élément pourrait faire référence à tout parent.

Mais dans votre application, vous savez que les relations sont redondantes . Vous savez que les relations ne doivent pas être stockés séparément dans la base de données. Vous décidez donc de le stocker dans un, pointant de l'article à la mère clé étrangère . Cette information minimale suffit pour construire la liste et la référence arrière.

Tout ce que vous devez faire pour mapper ce avec NH est:

• utiliser la même clé étrangère pour les relations
• NH dire que l'une (la liste) est redondante à l'autre et peut être ignoré lors du stockage de l'objet. (C'est ce que NH fait en fait avec inverse="true")

Ce sont les pensées qui sont pertinentes pour inverse. Rien d'autre. Il est pas un choix, il n'y a qu'une seule façon de cartographie correcte.

---

Le problème Spy : Il est une discussion complètement différente si vous voulez soutenir une référence de l'article au parent. Ceci est à votre modèle d'affaires, NH ne prend pas de décisions dans ce domaine. Si l'une des relations manque, il y a bien sûr pas de redondance et aucune utilisation de inverse.

Utilisation abusive: Si vous utilisez inverse = « true » sur une liste qui n'a pas de redondance en mémoire, il ne fonctionne tout simplement pas stocké. Si vous ne spécifiez pas l'inverse = « true » si elle doit être là, NH peut stocker les informations redondantes à deux reprises.

Answer 3

Si vous voulez avoir une association unidirectionnelle dire que les enfants ne peuvent pas naviguer au parent. Si oui, vous devriez être en colonne FK NULLABLE parce que les enfants seront sauvés avant que le parent.