-
1. Re: Aggregate roots and revisions
fbascheper Sep 15, 2010 1:53 PM (in response to jonssonth)Hi,
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:
* a.b.c.d
* a.f.h
* a.i
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
Etc.
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")
WDYT?
Regards,
Erik-Berndt
-
2. Re: Aggregate roots and revisions
jonssonth Sep 16, 2010 3:20 AM (in response to fbascheper)Hi!
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.
Best regards,
Thomas