Quick Guide on Loading Initial Data with Spring Boot

1. Overview

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

But we'll sometimes need more fine-grained control over the database alterations. And 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.

Please note that script-based initialization i.e. through schema.sql and data.sql and Hibernate initialization together can cause some issues.

Either we disable Hibernate automatic schema creation:

spring.jpa.hibernate.ddl-auto=none

This will ensure that script-based initialization is performed using schema.sql and data.sql directly.

If we still want to have both Hibernate automatic schema generation in conjugation with script-based schema creation and data population, we'll have to use:

spring.jpa.defer-datasource-initialization=true

This will ensure, that after Hibernate schema creation is performed then additionally schema.sql is read for any additional schema changes and data.sql is executed to populate the database. 

Also, script-based initialization is performed by default only for embedded databases, to always initialize a database using scripts, we'll have to use:

spring.sql.init.mode=always

Please refer to official Spring documentation on initializing databases using SQL scripts.

4. Controlling Database Creation Using Hibernate

Spring provides a JPA-specific property that 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 and 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 longer 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.sql.init.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 want to initialize its schema, we'll have to set this property to always.

This property was introduced in Spring Boot 2.5.0; we need to use spring.datasource.initialization-mode if we are using previous versions of Spring Boot.

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());
    }
}

Here are the attributes of the @Sql annotation:

• 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'll 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 we can use it 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. We can utilize this feature for @Sql annotations as well. For Java 7 and below, there is a container annotation — @SqlGroup.

Using the @SqlGroup annotation, we'll 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 looked at how to 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, and 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.

Persistence footer banner

An intro SPRING data, JPA
and Transaction Semantics Details with JPA

Get Persistence right with Spring

Download the E-book