NHibernate 3.x löscht untergeordnete Elemente beim Kombinieren von LINQ-Paging, Viele-zu-Viele und Unterauswahl Abruf

9

Unsere Anwendung hat das Konzept Stories und das Konzept Tags . Für eine Story können viele Tags verwendet werden, und ein Tag kann auf viele Storys angewendet werden, wodurch die Beziehung "Viele-zu-Viele" entsteht. Die beiden Tabellen Stories und Tags werden mit einem dritten StoriesToTags überbrückt.

Die relevanten Teile der Zuordnungsdateien sind wie folgt:

Hier ist das Mapping von Story zu Tag :

%Vor%

Und die umgekehrte Beziehung von Tag zu Story :

%Vor%

Wie Sie sehen, verwenden wir die Abrufstrategie subselect , um das N + 1-Abfrageproblem zu vermeiden. Alles funktioniert gut, bis Sie versuchen, ein Ergebnis mit LINQ zu paginieren:

%Vor%

Nach dem Ausführen dieser Abfrage löscht NHibernate die Beziehungen (Datensätze in StoriesToTags ) für alle Storys, die nicht in die Abfrage geladen wurden. Es scheint nur aufzutreten, wenn die Tags spezifisch geladen sind (das heißt, der Subselect wird ausgelöst). Die Beziehungen werden nicht gelöscht, wenn wir zu einer join oder ausgewählten Abrufstrategie wechseln, was jedoch dazu führt, dass N + 1 Abfragen ausgeführt werden.

Meine beste Vermutung ist, dass NHibernate denkt, dass die Tags verwaist sind, aber wir haben keine Kaskaden für die Sammlungen festgelegt. Soweit ich das beurteilen kann, hat das Setzen einer Kaskade keine Auswirkung.

Dieser Prozess hat unter NHibernate 2.x und NHibernate.Linq funktioniert. Wir haben das Problem mit dem Löschen nicht bemerkt, bis wir zu NHibernate 3.x gewechselt sind, wo die LINQ-Unterstützung eingebaut ist. Ich bin mir nicht sicher, ob es einen Unterschied macht, aber für das, was es wert ist, verwenden wir SQL Server mit Identitätsschlüsseln.

Irgendwelche Gedanken? Ich dachte zuerst, dass ich etwas wahnsinnig Dummes mache, aber ich habe im Grunde jede Veränderung des Mappings versucht und wir scheinen das Problem nicht zu beseitigen.

Bearbeiten: Eine weitere interessante Information. Wenn Sie session.IsDirty() vor dem Schließen der Sitzung aufrufen, tritt das Problem nicht auf. Ich vermute, dass dies daran liegt, dass die Änderungen der Sammlung nicht zwischen den Spülungen bestehen, aber ich kann die Quelle von NHibernate nicht gut genug entschlüsseln, um es genau zu wissen.

    
Nate Kohari 24.05.2011, 14:57
quelle

2 Antworten

1

haben Sie in der Zuordnung der Entität eingerichtet: Cascade.None () das wird aufhören, etwas anderes als die Entität zu löschen.

Dies könnte helfen: Ссылка

    
cpoDesign 01.08.2011 15:30
quelle
0

Können Sie uns einen Hinweis geben, was Sie hier erreichen wollen? Ich habe nie mit einem spezifizierten Abruf auf einem Viele-zu-Viele experimentiert, aber ich denke, dass es etwas mit einer Art expliziter Kaskade zu tun hat - alles für viele zu viele.

    
Tom Marien 24.05.2011 15:17
quelle