Ich versuche, ein Audit-Tracking für Nhibernate zu schreiben, das sich am PreUpdate-Ereignis beteiligt. Ich habe eine AuditLogEntry-Klasse (wann, wer usw.), die eine Liste von AuditLogEntryDetails enthält (d. H. Einzelne Eigenschaften, die sich geändert haben). Wenn ich die AuditLogEntry-Klasse von der geprüften Entität isoliere, wird mein Code ohne Fehler ausgeführt. Wenn ich jedoch eine Liste von AuditLogEntrys zu der geprüften Entität hinzufüge, löst mein Code ein
ausSammlung [DomainObjects.AuditTracking.AuditLogEntry.Details] wurde nicht von verarbeitet flush ()
Assertionsfehler, wenn ich versuche, die geänderte Liste im Ereignis-Listener zu speichern. Dies geschieht nur dann, wenn das geprüfte Element bereits eine (oder mehrere) AuditLogEntry-Instanz in der Liste hat. Wenn keine Einträge vorhanden sind, wird eine neue Liste erstellt und der Entität hinzugefügt, die geprüft wird, und das ist in Ordnung.
Ich denke, durch das Isolieren des Problems auf das Obige würde es scheinen, als würde es die vorhandene Liste (faul) laden, um auch die neue Instanz von AuditLogEntry hinzuzufügen. Ich konnte jedoch nicht weiterkommen. Das Hinzufügen von "Lazy=" False "" zur Listenzuordnung scheint nicht hilfreich zu sein. Ich bin wirklich in den frühen Tagen der Verwendung von NHibernate, nachdem ich Konzepte aus dem HN 3.0 Kochbuch und diese Blog-Post . Mein Code ist dem sehr ähnlich, aber ich versuche, das Audit-Protokoll dem Element hinzuzufügen, das in einer Liste auditiert wird (und deshalb denke ich, dass ich das auch im Pre- und nicht im Post-Update-Event tun muss).
>Ein Schnappschuss der betreffenden Entitätsschnittstellen / Klassen ist:
%Vor%Für die Abbildungen, die ich habe:
AuditTrackedEntry.hbm.xml:
%Vor%lookupvalue.hbm.xml:
%Vor%Der EventListener PreUpdate Eventhandler ruft den folgenden Code auf: Die Zeilen, die das Problem verursachen, werden am Ende des Codeblocks kommentiert
%Vor%Wie bereits erwähnt, bekomme ich in dieser Konfiguration einen Assertionsfehler " collection [] wurde nicht von flush () verarbeitet". Wenn ich die obigen drei Zeilen und die Listenzuordnung in der Datei lookupcode.hmb.xml lösche, funktioniert alles wie erwartet, außer dass die geprüfte Entität keinen Verweis mehr auf ihre eigenen geprüften Elemente enthält.
Wir hatten ein sehr ähnliches Problem, genau dieselbe Ausnahme, aber in anderer Situation. Keine Lösung gefunden ...
Wir haben einen NH-Ereignis-Listener, der die Methoden IPreUpdateEventListener und OnPreUpdate für das Überwachungsprotokoll implementiert. Alles ist in Ordnung, um einfache Eigenschaften zu aktualisieren, die Überprüfung auf Fehler funktioniert gut, aber es gibt Probleme mit faulen Sammlungen. Wenn Sie ein Objekt aktualisieren, das eine verzögerte Erfassung aufweist und auf ein beliebiges Objektfeld in der Methode OnPreUpdate des Ereignis-Listeners zugreift, wird dieselbe Ausnahme wie oben erwähnt ausgelöst. Wenn lazy auf "false" gesetzt ist, verschwindet das Problem.
Es scheint also, dass es ein Problem mit faulen Sammlungen gibt (und keinen Einfluss der Sammlungsinitialisierung vor dem Speichern). Unser Problem ist nicht mit dem Erstellen neuer Sammlungselemente verbunden. nur vorhandenes Objekt gelesen, verursacht nur das Feld, das vom Ereignis-Listener zugreift, das Problem.
In Ihrem Fall, vielleicht, lazy wird nur auf false gesetzt, denn die Assoziation könnte das Problem beheben, aber auf der anderen Seite möchten Sie wahrscheinlich, dass die Sammlung faul ist. So schwer zu sagen, ob das Problem eine Auflösung hat oder stattdessen IInterceptor verwendet werden muss.
Ok, ich habe dein Problem gefunden, diese Linie verursacht das Problem tatsächlich.
%Vor%Sie können eine leere Sammlung nicht vor dem Speichern initialisieren, da EntityPersister die Sammlung nicht persistiert, sondern dass die Sammlung nicht verarbeitet wurde.
Auch wenn nHibernate Ereignis-Listener aufruft, funktionieren Kaskaden nicht (nicht sicher, ob dies beabsichtigt ist oder nicht). Auch wenn Sie das Detailelement später zur Sammlung hinzufügen, rufen Sie nur das Detail "save" und nicht das übergeordnete Element auf, sodass die Änderung nicht weitergegeben wird. Ich würde eine Neu-Faktorisierung empfehlen, damit die Artikel in dieser Reihenfolge vervollständigt werden ...
Detail, dann speichern,
AuditLogEntry, dann speichern,
Entität, dann aktualisieren.
Ich hatte genau das gleiche Problem, als ich EventListener benutzt habe. Ich habe die Eigenschaften einzeln durchlaufen, um Änderungen zu erkennen, einschließlich der Auflistung von Sammlungen. Wenn ich jedoch einen Check für die Sammlung mit NHibernateUtil.IsInitialized(collection) hinzugefügt habe, ist das Problem verschwunden. Ich würde die AssertionFailure-Ausnahme nicht abfangen und ignorieren, da sie möglicherweise unbekannte Nebenwirkungen hat.
Es gibt ein Problem, das zur Lösung dieses Problems noch offen ist. Es gibt einen Patch am Ende des Themas, der es mir gelöst hat.
Tags und Links event-listener nhibernate