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.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…