Less than 2 months after Hibernate 4.0, JBoss has already released version 4.1 of Hibernate, the open source Object/Relational (O/R) mapping framework. Whilst this minor update includes several fixes and improvements, there is also a very interesting new feature in the audit module of Hibernate (previously known as Envers).
A common requirement in enterprise applications is the storage of historical database data. The database keeps previous versions of the data for reference purposes so that past decisions can be re-created by looking at the respective version of data. In security sensitive organizations, database auditing is also a strict requirement. At any point in time one should be able to read a "backlog" and understand all transitions of a database table up to its current state (along with the respective user that performed each change).
This requirement can, of course, be implemented with custom in-house code. An example solution would entail having a second table that keeps all transitions for each database table that needs to be audited. Therefore the first table keeps only the current state of the data, while the helper table keeps all intermediate states with some additional metadata (i.e. a timestamp and the user that initiated the change). This implementation requires all existing code that affects the database to be changed into a two step process, where the first step is saving the previous state into the history table and the second step is the actual change as before. It also means that all new code must be implemented following this principle, making the solution very code intrusive.
The Hibernate Envers module solves this problem in a transparent manner. The guiding principle of having an additional history table for each audited Entity still holds but all history management is automatically handled by Envers behind the scenes in an automatic way. The application code is mostly unchanged (assuming that Hibernate Annotations are already used). Envers functions in a manner similar to Subversion, meaning that each change creates a new global revision in the database.
Envers comes with its own API that allows for querying the database under a specific revision in the past instead of looking at the current state. Envers was integrated in Hibernate core in version 3.6 (and has been lately included in JBoss Application Server as well), so all the described functionality so far was already available in Hibernate 4.0
New in Hibernate 4.1 is the ability for tracking changes in individual Entity properties. Consider a scenario where the present state of an audited property is incorrect or suspicious and the user of the application wants to find the version where the last change happened for this specific property. Currently the API of Envers can be used to retrieve a previous revision of the object and then a diff is needed to determine if this revision was also responsible for this change. But with the new hasChanged() method of the AuditProperty class the exact revision(s) can be pinpointed directly.
For more information see the updated Javadocs.
