Then to get the configuration of any item at that locked version, we would query for the entity at the maximum revision less than or equal to the locked revision number we saved.
It does not seem like AuditReader can do that, unless I am missing something.
To do this, one would either need to getRevisions to find the right one and then call find, or build a custom version of AuditReader.
Working off the assumption that you have this "locked version" value somewhere against to be queried by, this is extremely simple:
List<YourEntityClass> results = auditReader.createQuery() .forRevisionsOfEntity( YourEntityClass.class, true, false ) .add( AuditEntity.revisionNumber().le( lockedVersionValue ) ) .addOrder( AuditEntity.revisionNumber().desc() ) .setMaxResults( 1 ) .getResultList();
If this doesn't exactly solve your problem, let me know.
Also, if an entity A has a child entity C, and an attribute on A is changed but no attributes on C are, and then A is persisted, will there be audit entries for C? If not, and you ask to find A at that revision, what do you get for C?
So lets assume that EntityA and EntityC (which are related) are persisted in a single transaction, e.g. revision 1.
At some future point, EntityA is modified by changing a property which is unrelated to EntityC, e.g. revision 2.
When you query for revisions of EntityC, you'd get only 1, revision 1.
When you query for revisions of EntityA, you'd get 2, revisions 1 and 2.
When you query for EntityA at revision 1, you'd get EntityC at revision 1.
When you query for EntityA at revision 2, you'd get EntityC at revision 1.
In other words, Envers always applies for ManyToOne/OneToOne audited relations to fetch the associated entity with a revision number that is less-than or equal-to the revision of the query's root entity.