Quick Guide on Loading Initial Data with Spring Boot

1. Overview

Spring Boot makes it really easy to manage our database changes in an easy way. If we leave the default configuration, it’ll search for entities in our packages and create the respective tables automatically.

But sometimes we’ll need some finer grained control over the database alterations. That’s when we can use the data.sql and schema.sql files in Spring.

2. The data.sql File

Let’s also make the assumption here that we’re working with JPA – and define a simple Country entity in our project:

@Entity
public class Country {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    private Integer id;
    
    @Column(nullable = false)
    private String name;

    //...
}

If we run our application, Spring Boot will create an empty table for us, but won’t populate it with anything.

An easy way to do this is to create a file named data.sql:

INSERT INTO country (name) VALUES ('India');
INSERT INTO country (name) VALUES ('Brazil');
INSERT INTO country (name) VALUES ('USA');
INSERT INTO country (name) VALUES ('Italy');

When we run the project with this file on the classpath, Spring will pick it up and use it for populating the database.

3. The schema.sql File

Sometimes, we don’t want to rely on the default schema creation mechanism. In such cases, we can create a custom schema.sql file:

CREATE TABLE country (
    id   INTEGER      NOT NULL AUTO_INCREMENT,
    name VARCHAR(128) NOT NULL,
    PRIMARY KEY (id)
);

Spring will pick this file up and use it for creating a schema.

It’s also important to remember to turn off automatic schema creation to avoid conflicts:

spring.jpa.hibernate.ddl-auto=none

4. Controlling Database Creation Using Hibernate

Spring provides a JPA-specific property which Hibernate uses for DDL generation: spring.jpa.hibernate.ddl-auto.

The standard Hibernate property values are: create, update, create-drop, validate and none:

• create – Hibernate first drops existing tables, then creates new tables
• update – the object model created based on the mappings (annotations or XML) is compared with the existing schema, and then Hibernate updates the schema according to the diff. It never deletes the existing tables or columns even if they are no more required by the application
• create-drop – similar to create, with the addition that Hibernate will drop the database after all operations are completed. Typically used for unit testing
• validate – Hibernate only validates whether the tables and columns exist, otherwise it throws an exception
• none – this value effectively turns off the DDL generation

Spring Boot internally defaults this parameter value to create-drop if no schema manager has been detected, otherwise none for all other cases.

We have to set the value carefully or use one of the other mechanisms to initialize the database.

5. Customizing Database Schema Creation

By default, Spring Boot automatically creates the schema of an embedded DataSource.

If we need to control or customize this behavior, we can use the property spring.datasource.initialization-mode. This property takes one of three values:

• always – always initialize the database
• embedded – always initialize if an embedded database is in use; this is the default if the property value is not specified
• never – never initialize the database

Notably, if we are using a non-embedded database, let’s say MySQL or PostGreSQL, and wish to initialize its schema, we’ll have to set this property to always.

6. @Sql

Spring also provides the @Sql annotation — a declarative way to initialize and populate our test schema.

Let’s see how to use the @Sql annotation to create a new table and also load the table with initial data for our integration test:

@Sql({"/employees_schema.sql", "/import_employees.sql"})
public class SpringBootInitialLoadIntegrationTest {

    @Autowired
    private EmployeeRepository employeeRepository;

    @Test
    public void testLoadDataForTestClass() {
        assertEquals(3, employeeRepository.findAll().size());
    }
}

The attributes of the @Sql annotation are:

• config – local configuration for the SQL scripts. We describe this in detail in the next section
• executionPhase – we can also specify when to execute the scripts, either BEFORE_TEST_METHOD or AFTER_TEST_METHOD
• statements – we can declare inline SQL statements to execute
• scripts – we can declare the paths to SQL script files to execute. This is an alias for the value attribute

The @Sql annotation can be used at the class level or the method level. We can load additional data required for a particular test case by annotating that method:

@Test
@Sql({"/import_senior_employees.sql"})
public void testLoadDataForTestCase() {
    assertEquals(5, employeeRepository.findAll().size());
}

7. @SqlConfig 

We can configure the way we parse and run the SQL scripts by using the @SqlConfig annotation.

@SqlConfig can be declared at the class level, where it serves as a global configuration. Or it can be used to configure a particular @Sql annotation.

Let’s see an example where we specify the encoding of our SQL scripts as well as the transaction mode for executing the scripts:

@Test
@Sql(scripts = {"/import_senior_employees.sql"}, 
  config = @SqlConfig(encoding = "utf-8", transactionMode = TransactionMode.ISOLATED))
public void testLoadDataForTestCase() {
    assertEquals(5, employeeRepository.findAll().size());
}

And let’s look at the various attributes of @SqlConfig:

• blockCommentStartDelimiter – delimiter to identify the start of block comments in SQL script files
• blockCommentEndDelimiter – delimiter to denote the end of block comments in SQL script files
• commentPrefix – prefix to identify single-line comments in SQL script files
• dataSource – name of the javax.sql.DataSource bean against which the scripts and statements will be run
• encoding – encoding for the SQL script files, default is platform encoding
• errorMode – mode that will be used when an error is encountered running the scripts
• separator – string used to separate individual statements, default is “–“
• transactionManager – bean name of the PlatformTransactionManager that will be used for transactions
• transactionMode – the mode that will be used when executing scripts in transaction

8. @SqlGroup 

Java 8 and above allow the use of repeated annotations. This feature can be utilized for @Sql annotations as well. For Java 7 and below, there is a container annotation — @SqlGroup. Using the @SqlGroup annotation, we can declare multiple @Sql annotations:

@SqlGroup({
  @Sql(scripts = "/employees_schema.sql", 
    config = @SqlConfig(transactionMode = TransactionMode.ISOLATED)),
  @Sql("/import_employees.sql")})
public class SpringBootSqlGroupAnnotationIntegrationTest {

    @Autowired
    private EmployeeRepository employeeRepository;

    @Test
    public void testLoadDataForTestCase() {
        assertEquals(3, employeeRepository.findAll().size());
    }
}

9. Conclusion

In this quick article, we saw how we can leverage schema.sql and data.sql files for setting up an initial schema and populating it with data. We also saw how we can use @Sql, @SqlConfig, and @SqlGroup annotations to load test data for tests.

Keep in mind that this approach is more suited for basic and simple scenarios, any advanced database handling would require more advanced and refined tooling like Liquibase or Flyway.

Code snippets, as always, can be found over on GitHub.