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
