Right now we are just using the implementation of the spring-data-envers project and this seems not to be very extendable. In a prior project we used the Envers AuditReader directly and created a api very similiar to the spring-data-envers project. But we decided to use this one on our actual project.

I am inclined not to change the current #find implementation as I’m afraid there may be users that are expecting the behavior that you found to be problematic..

Of course not. We spoke about override or intergrate a own strategy or something like that, but at this point there is no way to have an overview about possible side effects if we change this subquery. So we droped the idea instantly.

Your example could be a possible solution, but then we ll have change the whole repository. We could create some kind of validator before calling the find method to ensure that there is definetly the exact combination of entity and revision or raise an error. I guess well wait what you and your team decide on this one and then think about our options.

Thanks for your effort.