Contact - Id: 1, First name: Tom, Last name: Jackson, Birthday: 2011-10-21, Create by: prospring3,
Create date: 2011-10-21T10:45:52.483+08:00, Modified by: prospring3, Modified date: 2011-10-
21T10:45:52.596+08:00
In the previous output, you can see that after the new contact is created, the create date and last
modify dates are the same. However, after the update, the last modified date is updated. Auditing is
another handy feature that Spring Data JPA provides so that you don't need to implement the logic
yourself.
This wraps up our discussion of Spring Data JPA. Let's move on to see another useful function that
Hibernate provides for keeping entity versions.
Keeping Entity Versions by Using Hibernate Envers
In an enterprise application, for business-critical data, it is always a requirement to keep "versions" of
each entity. For example, in a customer relationship management (CRM) system, each time a customer
record is inserted, updated, or deleted, the previous version should be kept in a history or auditing table
to fulfill the firm's auditing or other compliance requirements.
To accomplish this, there are two common options. The first one is to create database triggers that
will clone the pre-update record into the history table before any update operations, and the second is to
develop the logic in the data access layer (e.g., by using AOP). However, both options have their
drawbacks. The trigger approach is tied to the database platform, while implementing the logic
manually is quite clumsy and error prone.
Hibernate Envers (Entity Versioning System) is a Hibernate module specifically designed to
automate the versioning of entities. In this section, we will discuss how to use Envers to implement the
versioning of the ContactAudit entity.
■ Note Hibernate Envers is not a feature of JPA. We mention it here because we believe it's more appropriate to
cover this after we have discussed some basic auditing feature that you can do with Spring Data JPA. As a matter
of fact, maintaining history records of critical business data (e.g., customer, transaction, and so on) is a basic
feature in an enterprise application.
Envers supports two different auditing strategies, which are shown in Table 10-3.
Table 10-3. Envers Auditing Strategies
Auditing Strategy
Description
Default
Envers will maintain a column for the revision of the record. Every time a record is
inserted or updated, a new record will be inserted into the history table with the
revision number retrieved from a database sequence or table.
Validity Audit
This strategy stores both the start and end revisions of each history record. Every
time a record is inserted or updated, a new record will be inserted into the history
table with the start revision number. At the same time, the previous record will be
updated with the end revision number. It's also possible to configure Envers to
record the timestamp at which the end revision was updated into the previous
history record.
Search WWH :
