Working around envers

When using envers for in our implementation, on the simplistic implementation, it does not provide much information on what the transaction is about. To get around this, we had no choice but to input the transactional information at the action level. This will also allow all information to be in a transaction table, in this case the "MA_Transaction".

The transaction table shall also be audited to tag the revision number to it, when envers audits it. This finally "MA_Transaction_AUD" table will contain the revision + Transaction, giving a consolidated table of all transaction information.

The key thing to note is that both the entity persistence and the transaction persistence have to be done within one transaction to ensure that the revision is properly replicated in the "MA_Transaction_AUD" table.

Though, this design is not a clean and straightfoward one, this was necessary to get this it working the way we need to, when we were supposed develop an enquiry facility.

How envers can work for you

Recently, i was using envers as a quick method to perform logging for my application. I have some positive and negative thoughts at this method.

It works in the following way:

Advantages

• Simple to implement transactional information.
• Audit Reader to query the audit records to find entity at a particular revision

Disadvantages

• Creates multiple Audit tables
• Very hard to document function that has modified the entity
• Need 2 Audit Reader queries to retrieve the before and after values
• Need to query all entities when trying to find out which table each revision has impacted.