Spring Data JPA : Auditing with @CreatedBy, @CreatedDate, @LastModifiedBy and @LastModifiedDate

 

What is database Auditing?

database auditing means that keeping a track and log of the events (specially create and update) associated with the persistent entities. It keeps a track of who created or changed an entity and when the change happened.

I have seen projects storing these things manually. Doing so becomes very complex because you will need to write it completely on your own, which will definitely require lots of code — and lots of code means less maintainability and less focus on writing business logic.

But why should someone need to go to this path when both JPA and Hibernate provide automatic auditing, which we can be easily configured in your project? Basically the following information are maintained with database auditing.

  • created user (who created)
  • created date (when created)
  • last updated user (who updated)
  • last updated date (when updated)

 

Auditing with Spring Data JPA

Spring Data JPA provides some set of convenient and useful annotations for database auditing. It helps to keep a track of who did the change and when it was done.

Here in this article, I will discuss how we can configure JPA to automatically persist the audit related columns (created and modified information) for any entity with following annotations. (All these annotations are owned by the Spring Data JPA)

  • @CreatedBy
  • @CreatedDate
  • @LastModifiedBy
  • @LastModifiedDate

 

Source Code and Project Structure

The source code of this article can be found at GitHubClick here to download it. The complete project structure should looks like below.

Screen Shot 2018-06-01 at 12.00.03 AM.png

In this article, i will guide you through the all required steps of adding the Spring Data JPA Auditing feature for your application.  You can follow the instructions given below.

 

Create Spring Data JPA Project

The following dependencies should be added for the newly created spring boot project.

  • Spring Data JPA
  • Spring Web
  • MySQL Driver
  • Lombok

 

Screen Shot 2018-05-31 at 10.58.24 PM.png

 

 

Important!

To make this article simple and relevant with the topic, i am just adding/showing only the relevant classes and configurations related to the Spring Data JPA auditing feature.  If you need to look at the full source code, please download it from GitHub.

For all the classes, we have use the Lombok library. Therefore no need to explicitly provide the getters/setters.  They will be automatically added by the Lombok library.

 

User.java

 

This is the User entity class which manages the “users” table.  This class is extended from the Auditable class.  Here is the source code of the Auditable class.

 

 

The overall idea behind this class (Auditable) is to provide the required attributes and columns for the database (table) auditing.  If you need to enable the auditing feature for any entity class, you need to simply extend that class from this (Auditable) class.  Since the User entity is extended from the Auditable class,  it will be inherited with all the auditing related attributes defined in the Auditable class.

@MappedSuperclass :- Designates a class whose mapping information is applied to the entities that inherit from it. A mapped superclass has no separate table defined for it.

AuditingEntityListener :- Spring Data JPA provides a JPA entity listener class, AuditingEntityListener, which contains the callback methods (annotated with the @PrePersist and @PreUpdate annotations), which will be used to manage (persist or update) audit related properties when the entity is persisted or updated.

@EntityListeners can be used to specify listener classes which will listen for the event of the entities through some annotated methods. If any event is occurred, the relevant annotated method will get notified. We have registered AuditEntityListener as the entity listener class.  

 

 

Enable Spring Data JPA Auditing Feature

Now we need to make the relevant configuration for enabling the audit related feature with Spring Data JPA.  The following JpaAuditingConfiguration class does the job for us.

 

@EnableJpaAuditing will enable the Spring Data JPA Auditing features for the application.  This annotation has the capability of managing (persisting and updating) the date related audit fields  such as @CreatedDate and @LastModifiedDate.

But there are some user related audit fields such as @CreatedBy and @LastModifiedBy will require the information of the currently logged in user. In order to manage (persist and update) those fields, we need to give a way to access the currently logged user for the  JPA auditing feature.

To tell Spring Data JPA about currently logged-in users, we will need to provide an implementation of AuditorAware interface and override the getCurrentAuditor() method. getCurrentAuditor() should implement to return the currently logged-in user.

 

Current Auditor with Spring Security

For the demonstrating purpose of this article, i have hard coded a static text (“chathuranga“) as the currently logged in user when implementing the getCurrentAuditor() method of the AuditorAware interface.  But for the production use, you  need to get the currently logged in user with the underlying authentication and authorization framework such as Spring Security.

If you are using Spring Security, you can access the currently logged in user with following code line.

SecurityContextHolder.getContext().getAuthentication().getName()

 

Now  i have shown you a the all the required classes and configurations related to the Spring Data JPA auditing feature. Apart from these classes, there are some other classes that helps to build this demo application.  Everything is added to GitHub and you can download them .

 

Running the demo application.

Clone the source code from the GitHub and change the database related configurations.

 

Then run the application as follows.

mvn spring-boot:run

 

Access the  /users endpoint with following request body.

POST    http://localhost:8080/users

Screen Shot 2018-05-31 at 11.56.18 PM.png

 

If you look at the table structure, you can see that  audit related fields are added to the “users” table.

Screen Shot 2018-05-31 at 11.57.08 PM.png

 

By observing the “users” table, you can notice that all the audit related fields are populated with relevant values as follows.

Screen Shot 2018-06-01 at 4.53.56 PM.png

 

This is the end of this article and if you need any clarification related to this article, Please feel free to get back.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s