JPA and Hibernate settings

In this topic, we are going to talk about the most important properties of Spring Data JPA and Hibernate. Their settings corresponding to the specifics of your project make the development easier, and, as a result, your application becomes faster and has fewer errors. Let's learn how to do it!

DDL operations with Spring Data and Hibernate

Data Description Language (DDL) is a syntax for creating and modifying database structure. As you already know, Spring Data can create database tables by given entities on its own. Also, it can change the table structure and delete tables. We can define the way Spring Data will use these DDL operations by the spring.jpa.hibernate.ddl-auto property. It has 5 options:

• create

• create-drop

• update

• validate

• none

If we choose the create option, Hibernate first drops existing tables and then creates new ones based on entities. create-drop is the same as create, but Hibernate deletes all the tables after the application stops. This option is convenient for application testing and is default for the embedded databases.

If we choose update or validate options, Hibernate compares entity configurations with the database schemas. If they don't match, Hibernate tries to do something about it. In the case of the update option, Hibernate changes the database schema. However, Hibernate can only extend these schemas — it's not allowed to delete anything with such a configuration. In the case of the validate option, Hibernate throws an exception and the application stops.

If we want Hibernate to do nothing with the database schemas, the none option is a good choice. If we choose it, Hibernate just doesn't perform any DDL operations. This option is default for external databases. You can use the following decision tree to make a right choice of the property value:

Other settings for working with databases

The spring.jpa.database-platform property is used to define the database you will work with and inform Spring Data which SQL dialect it to use. For example, if we use the H2 database, we need to define the following property:

spring.jpa.database-platform=org.hibernate.dialect.H2Dialect

We can turn on the logging of the SQL queries that Hibernate creates. We may do this with the following property:

spring.jpa.properties.hibernate.show_sql=true

And now all the queries are logged to the console! We may make our log prettier if we turn on this setting:

spring.jpa.properties.hibernate.format_sql=true

Another important property is spring.sql.init.mode, with the help of which you can enable and disable SQL scripts execution for database pre-population. This property may have three values: always, never, and embedded. The last option is the default one. It means that if our database is embedded, the scripts are launched.

The property spring.jpa.defer-datasource-initialization may come in handy when we use SQL scripts for database pre-population together with Hibernate schema creation. If the value of this option is true, Hibernate first performs its DDL operation, and then SQL scripts are launched. And if the value is false, which is default, SQL scripts are launched before the DDL operations of Hibernate.

Open Session In View

When starting a Spring Boot application, we can notice the following log in our console:

spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed 
during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning.

Let's understand what it means. The property spring.jpa.open-in-view allows us to enable and disable the usage of the controversial concept Open Session In View (OSIV). Its essence lies in leaving the Hibernate session open while processing the HTTP request. This concept allows developers not to think about lazy loading of the data because the connection with the database remains open and the data needed can be requested from the database in any part of the application. We can turn off this pattern by adding the following line to application.properties:

spring.jpa.open-in-view=false

But now we need to handle LazyInitializationException. So, the OSIV patten makes the life of the developers easier, allowing them not to think about lazy loading. However, this concept has a lot of disadvantages. The application that uses Open Session In View is harder to test because the requests to a database can be sent from different layers of the application. Also, many open connections to a database slow down the work of the application.

Many developers consider Open Session In View as the antipattern. Of course, we won't see any difference in small application's performance. But when we have an application with lots of users, OSIV can sufficiently slow down its work.

Conclusion

In this topic, we discussed the main settings of Hibernate and Spring Data JPA for working with databases. You also learned about the controversial pattern Open Session In View and found out about its pros and cons. Now your work with the databases will be easier and more transparent!