Here is my use case
I have two entities : Personn and Email (a @OneToMany relation). Both of them are audited.
First I create a new Personn, with an Email (=> Both of them have a revision 1), then I modify the Email (=> The Email has a revision 2, but Personn has only a revision 1)
In the web application the end-user has only one view to show the Personn's attributs and also his Emails attributs. In this view I want to show all existing revisions for this Personn. But when I query the audit system, it doesn't show me revision 2 as the Personn has not been modified.
I understand the technical problem, but in the end-user point of view, he wants to see a revision 2 because he modified the personn's email ! He doesn't know (and doesn't have to know) that we deciced to divide these information into 2 Java objects. Of course this problem is not only for Personn-Email relation (I've got a lot of relation between Personn and other objects which are shown in the same view - Adress, Job, Site, Card, and many more)
I thought about 2 solutions:
1- Querying all relations to know if a Revision exist (but I suppose it will generate a big request or multiple requests - I've got a lot of relations).
2- Setting "hibernate.listeners.envers.autoRegister" to false, writing my own EnversIntegrator and event implementations. In event implementations (which override default Envers implementations), I will create a ModWorkUnit for Personn when Email's attributs have been modified (it will not been hard coded of course: perharps a custom annotation like @AuditedPropagation on the personn field). The flaw of this solution is to create a lot a row for Personn even if it was not modified.
What do you think about these solutions ? Do you know a better way to solve that kind of use-case ?
Thanks for your advices.
I tried to implement the second solution:
First my integrator which adds a new post update listener (RevisionOnCollectionPostUpdateEventListenerImpl)
And then the post update listener (which extends):
It seems to work but I have to test a little bit more.
I have been unable to make the custom post update listener solution work. addCollectionChangeWorkUnit doesn't seem to exist until hibernate 4.1 where it is marked private. EnversPostUpdateEventListenerImpl seems to appear at some point in hibernate 4.0
I solved my problem by adding a hidden lastUpdated date field on my equivalent of your A entity.
In the related entities (like you B field), I added the following :
This ensures that a revision is added to A whenever a revision is added to B even though it requires custom code in many entities.