In our application, we often have a need to make database changes using a sql update call. This means that we don't go through hibernate entity persist, and so don't get envers auditing the change.
We have solved this by creating an explicit RevisionEntity and persisting that, and using its id field to insert into the envers audit tables manually with similar sql insert calls to the update.
This works fine, but it does mean that we get two separate audit revisions. Revision N is the one created by envers at the end of the transation, and links to any entities saved by hibernate, and N-1 is the revision we have created before completing the hibernate session and where we have done our bulk sql audits.

I would like to propose a fix for this, that would allow envers to skip saving the RevisionEntity object if the code has flagged that revision as an already existing object.
We are using a modified AuditProcess, where getCurrentRevisionData() simply skips saving and adds the object to the session if the RevisionEntity itself returns true for a new method `isAlreadyPersisted`.

Before I go through putting together a patch with tests, can someone who knows envers better than me tell me if I'm barking up the wrong tree, or if there is a better approach here? The goal is simply to stop envers creating a new object for the transaction commit and instead use one returned by the RevisionListener implemented by the developer.