EnversRevisionRepositoryImpl::findRevision change in behaviour

[neil-ca-moore]

Somewhere between 2.1.17 and 2.5.6, the behaviour of this function has changed. I can work on a minimal repro case if required, but before I go to that effort I just want to check whether anybody is aware of this (I couldn't find it in the release notes)? Also it might be a different project that the bug should be filed against?

Please let me know next steps?

Thanks.

Scenario:

Entity E_1 and E_2 both annotated with @Audited
Create entity E_1, at time T_1 at revision 1.
Create another entity E_2, at time T_2 at revision 2.
Postgres DB

Steps:
Call org.springframework.data.envers.repository.support.EnversRevisionRepositoryImpl#findRevision with arguments

ID =
revisionNumber = 2

Result at spring-data-envers 2.1.17:

Result E_1 at revision 1

Result at spring-data-envers 2.5.6:

Optional.empty()

Conclusion:

It seems like the behaviour changed from returning the most recent version at that revision or earlier, to returning only the specific revision requested?

[schauder]

Yes, please provide a reproducer.

[neil-ca-moore]

@schauder I wrote a test that fails in more recent versions. I used 2.5.6 because that's where I found it.

I also wrote the same test against an earlier version (2.1.17), that test passes.

So it seems there has been a change of behaviour, whether in the spring-data-envers project or maybe a dependency.

Wondering which is the correct behaviour?

For background, we are using this code to achieve fetching by date. By using AuditReader to get a revision number for a date, then fetching that revision using RevisionRepository.

There is already a request for that to be implemented directly: #301.

Thank you for your help.

[neil-ca-moore]

@schauder Wondering your thoughts on this, please?

[neil-ca-moore]

Wondering what will happen with this issue, please? @christophstrobl you have been active on the project recently.

[em2e]

This caused a problem for me too! The behavior was changed in 2.3.0.RC2.
Before this change the envers AuditReader.findRevision method was used, and it finds the most recent version up to the given revision number (less than or equal to). After the change the code use it's own query:
createBaseQuery(id).add(AuditEntity.revisionNumber().eq(revisionNumber))
so it finds only the exact match.
I thing the envers original logic is what we expect here.