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]> > 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 >
