<<Didn't have time to look into the second issue right now. Do you have some proposal for code changes?>>
For Envers to be able to compare collections before/committed a transaction, it needs some way to figure out before state in cases where it's not available out-of-the-box (=scenarios where user or NH has replaced the collection instance since it was loaded) in the event listeners. In these scenarios, Envers needs to be able to load current db state inside OnPreXXXCollection methods. However currently, when the org collection isn't available, the AbstractCollectionEvent sent to these methods don't even include what property name or similiar it's all about. I'll try to find some time to verify that the property name of collection is enough info in my case. If so, I try to create appropiate NH patch. /Roger ________________________________ Från: [email protected] [[email protected]] för Oskar Berggren [[email protected]] Skickat: den 6 oktober 2012 17:53 Till: [email protected] Ämne: Re: [nhibernate-development] NHib help/change needed for Envers The double interfaces are an artifact of that PersistentGenericXXX inherits from its non-generic counterpart. For sets this is no longer the case in NH master (to prepare for .Net 4) so you shouldn't have that problem there. For the other non-generic collections, there seems to be no objection to removing the support, which should solve your problem also. Due to this inheritance, however, it is a bit more work than to just delete a couple of files. Didn't have time to look into the second issue right now. Do you have some proposal for code changes? /Oskar 2012/10/2 Roger <[email protected]<mailto:[email protected]>> Hi NH Core team There is a Envers bug that is (partly) hard to solve without NH Core changes I think. Just sending this mail to see if there’s any known workarounds available I’m not aware of or if some NH Core changes is possible. The Envers bug is https://nhibernate.jira.com/browse/NHE-64 which actually is two bugs in one regarding detached entities with collection(s). The first, simpler one, can be solved within Envers but I want to check with you if you agree that’s better to fix within NH Core instead. Envers has its own collection types used for lazy loading of audited collections. It’s simple proxies for ISet<T>, IList<T> etc. When user calls (SaveOr)Update on a audited entitiy with a collection, NH Core will try to replace the collection with a PersistentGenericXXX instance. Currently this throws because Envers’ collection implements the generic interface and not the non-generic counterpart. In PersistentGenericXXX ctors its expected that the collection implement _both_ these interface (eg ISet<T> _and_ ISet). Envers’ generic collections could be changed and implement both the generic and non-generic interface but I cannot really see why NH Core demands this extra dependency on the generic collections? Can you please give some input if you think it’s better to change NH Core or if Envers’ collections should implement two interfaces? And also, from what I’ve read on this list earlier, non-generic collections in general might be non-supported in the near future anyway (?). The second issue, the harder one because I believe it’s unsolvable without NH Core changes, is that “old state” of a collection isn’t available in the event listeners when the entity has been detached. Envers needs to know this “old state” to be able to persist audit changes of the collection(s). I totally understand that this is by design and can’t/shouldn’t be possible out-of-the-box. So far so good. The real problem though, that should be technical possible I think, is giving Envers (and other frameworks) a chance to fetch db state of the collection at persist time (in appropriate event listener) to get the “old state” that way. However, AFAIK - this can’t be done because the info about persister and/or role is not sent to the different event listeners if old state isn’t available. Hibernate has a similar (unresolved) “bug” reported here https://hibernate.onjira.com/browse/HHH-6882 To summarize... My first question – better to fix in Envers or in NH Core? My second question – Should I JIRA this or is there already a way to find out what collection property the event is about even if the collection/old state is null? All the best, Roger
