I think you can use tha AuditReader object. This interface do that sort of things...
It's something like:
AuditReader auditReader = AuditReaderFactory.get(entityManager); // or AuditReaderFactory.get(session);
You can have a look at AuditReader interface, there are other methods for history queries.
I hope it will help you. Hernán
Unfortunately no. reader.getRevisions(Class, id) only returns the revisions when the entity itself has changed. In my case however, not the person entity itself changed, but the associated address entity.
So reader.getRevisions(Class, id) only returns , where I would need a method that returns [1,3,4]
Oh! I see...
I think that's no possible to do automatically.
Think in another object with a reference to the same object (address in this case)... Envers would know all other objects pointing to this and generate a revision for each one... and there is no way to know all entities that points to another...
In that case I would perform a change in my master entity (a fake change) an envers will add a revision.
Maybe Adam knows other way.
Hope it helps. Hernán.
Hmmm. I think that's not what I want. Performing a fake change on my master entity would slow down every writing operation unnecessarily.
So if revision information of the detail entity is not stored in the audit log of the master entity in the database, you have to collect this information from the audit logs of the detail entities at runtime by walking all (audited) associations of the master entity class. Or am I missing something here?
Walking the associations should be possible in a generic way. I know it would be kind of slow, but on the other hand in 99% of all the use cases I'm only reading current data anyway. So I could live with the fact that building the revision list for the master entity would take some time in this one use case. Any thoughts on this?
Hernan is right that currently that's the only solution possible. I am aware of that limitation for quite some time . The solution would be of course to enable relation-traversing in queries, which is currently not possible, due to the complexity of history reading. This will be possible once the end-revision column support will be implemented, which is planned for a long time now, but unfortunately I still didn't have time to do it...