We're updating the issue view to help you get more done. 

Allow envers to reuse an audit revision

Description

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.

Environment

None

Status

Assignee

Chris Cranford

Reporter

Anton Piatek

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Priority

Minor