Atsortingbut inverse dans NHibernate

L’atsortingbut inverse ne doit pas être défini sur true …

Vous utilisez l’atsortingbut inverse pour spécifier le «propriétaire» de l’association. (Une association ne peut avoir qu’un seul propriétaire, donc une extrémité doit être définie sur inverse, l’autre doit être définie sur «non inverse»). (Propriétaire: inverse=false ; non-propriétaire: inverse=true )

Dans une association un-à-plusieurs, si vous ne marquez pas la collection comme extrémité inverse, NHibernate effectuera une mise à jour supplémentaire. En fait, dans ce cas, NHibernate insérera d’abord l’entité contenue dans la collection, insérera si nécessaire l’entité propriétaire de la collection, puis mettra à jour l’entité de collecte pour que la clé étrangère soit définie et l’association est fait. (Notez que cela signifie également que la clé étrangère de votre firebase database doit être nullable).

Lorsque vous marquez la fin de la collection en tant qu ‘«inverse», NHibernate va d’abord persister l’entité qui «possède» la collection et persistera ensuite les entités qui se trouvent dans la collection, en évitant une instruction UPDATE supplémentaire.

Donc, dans une association bidirectionnelle, vous avez toujours une extrémité inverse.

En plus de la réponse ci – dessus , et selon ce que je comprends, vous devez conserver la valeur de la clé étrangère dans la collection manuellement, c’est-à-dire si vous ne souhaitez pas obtenir la déclaration de mise à jour supplémentaire:

 Parent par = Session.Get(8); Child ch = new Child(); ch.Name = "Emad"; //set the parent foreign key manually ch.MyParent = par; par.MyChildren.Add(ch); Session.Save(par); 

pour plus d’explications sur l’atsortingbut inverse, vérifiez le post suivant:

http://www.emadashi.com/index.php/2008/08/nhibernate-inverse-atsortingbute/

Je peux voir où le “propriétaire” entre, mais une association est un canal, et vous pouvez regarder les deux extrémités, donc comment dire quelle entité “possède” le canal.

Une autre façon de voir les choses est que, dans une relation un à un, il existe en réalité deux relations.

Relation 1: Parent à plusieurs enfants.

Relation 2: Chaque enfant à un parent

Ainsi, NH tentera d’exécuter sql pour stocker chacun de ces éléments dans la firebase database. Mais il n’est pas nécessaire, car lorsque vous définissez la clé étrangère, par exemple dans la relation 2, lorsqu’un enfant est stocké, la relation d’un parent à l’enfant est automatiquement corrigée, car la relation 1 est l’inverse de la relation 2. .

Donc inversement, c’est quelque chose que nous obtenons par défaut une fois que nous avons défini la relation principale. Par exemple, il n’est pas nécessaire que NH exécute SQL pour corriger la relation 1 et en marquant la collection d’enfants comme un Inverse NH ignorera l’exécution de sql lorsque la collection d’enfants est ajoutée.

Je suppose que si vous n’aviez pas dit à NH que c’était un inverse, cela gaspillerait votre effort à essayer de mettre en place la relation inverse, même si cela n’était pas nécessaire.