Not that I know of. Another strategy could be a native query to retrieve rows from the audit-join tables.
You can of course take the plunge and write it yourself.
Ideally it should be possible to be able to define the size of a revision, in terms of a graph.
I.e. if you have in terms of properties:
And that you can define that changes in c (i.e. a.b.c) are still part of a revision of a
And the same for a.f (but not a.f.h)
And the same for a.i
Maybe (a first thought) this could be implemented in the term of revision-groups (as annotation).
Then you would define that entities a,b,c and f and i all have a revision group ("a-revision-graph")
Thanks for your answer. I like your idea regarding creating a revision group by annotations, and I will try that approach if I can't accomplish this by looking at the cascade attribute on the jpa relation annotations. So my solution would be:
1) Fetch revisions for aggregate root
2) Inspect all the fields on the aggregate root and if cascade=Cascade.ALL, Cascade.UPDATE, Cascade.REMOVE I will fetch the revisions for this class. Then I will inspect all the fields in this class and so on....
3) Finally, I will merge and sort the result.
If you in the Envers team like the solution, please let me know if I could contribute to the project.