Ich habe zwei ähnliche Abfragen, die theoretisch die gleichen Ergebnisse liefern:
%Vor% Diese Anforderung gibt 0 Elemente zurück, obwohl sie eins zurückgeben soll.
Das Folgende ist ein Neuschreiben des Letzteren, aber mit einem Aufruf der Methode ToList() . Diese Anfrage funktioniert und gibt das in der ersten Abfrage erwartete Element zurück!
Hinweis: SessionManagement.Db.Linq<Item>(false) ist eine generische Linq to Nhibernate-Methode, bei der das boolesche Attribut bestimmt, ob die Anforderung im Cache (true) oder in der Datenbank (false) ausgeführt werden muss. Es ist angeblich nichts falsch an dieser Methode, wie es normalerweise in vielen anderen Teilen der Lösung funktioniert. Das Mapping von Item ist nichts Besonderes: keine Taschen und die folgenden Parameter:
lazy="false" schema="dbo" mutable="false" polymorphism="explicit"
Warum ist das so?
Bearbeiten :
Die generierte SQL-Anfrage von requestNoWorking endet mit:
(Item.Group_ID is not null) and Item.Group_ID=@p0',N'@p0 int',@p0=11768
Die generierte SQL-Anfrage von requestWorking ist ungefähr ein select * from dbo.Items
Ich war sehr an Ihrer Theorie von c.Group.Id != null interessiert, die ich für logisch hielt, obwohl sie anderen Teilen meines Codes widersprach. Das Entfernen hat jedoch nichts geändert. Ich habe festgestellt, dass das Entfernen von mutable="false" -Eigenschaft das Problem gelöst hat. Es scheint ein wenig magisch, aber es hat funktioniert.
Die von mir geposteten Anfragen erfolgten tatsächlich in Methoden, die die Möglichkeit der Aktualisierung / Löschung prüfen. Meine Schlussfolgerung ist, dass das Unveränderlichmachen von Item die Ergebnisse verfälscht hat. Aber was ich nicht verstehe ist, warum requestWorking dann funktioniert!
Ich gehe davon aus, dass die Nhibernate-Sitzung, die Sie dort gemacht haben, eine Abfrage zurückgibt. Wenn dies der Fall ist, wird die Auswertung der ersten Abfrage bis zum Aufruf von .ToList() verzögert, und die gesamte Abfrage wird auf dem Server ausgeführt. Ich würde vorschlagen, dass Sie eine Ablaufverfolgung auf dem SQL-Server wenn möglich ausführen, oder laden Sie NHProf herunter, um zu sehen, was die tatsächliche Frage ist ausgeführt wird.
Die zweite Abfrage wird ausgewertet, sobald Sie das erste .ToList() treffen, also ziehen Sie die gesamte Tabelle aus der db zurück und filtern dann mit .net. Ich kann ehrlich gesagt nicht sagen, warum sie anders bewerten würden, aber ich nehme an, dass es etwas mit der Zuordnung / Konfiguration gibt, das verursacht, dass die DB-Abfrage etwas falsch geschrieben wird.
Alles, was ich sehen kann, ist, dass in der zweiten Version Ihr Where von LINQ zu Objects und nicht von LINQ zu NHibernate ausgeführt wird. Also muss die erste Version etwas tun, was LINQ zu NHibernate nicht gut verdaut.
Ich bin denk es ist die i.Group != null , mit der LINQ To NHibernate ein Problem hat, da die Verwendung von null CLR-spezifisch ist. Möglicherweise müssen Sie ein anderes Konstrukt in LINQ to NHibernate verwenden, um nach leeren Feldwerten zu suchen.
Tags und Links .net c# linq linq-to-nhibernate