
Baeldung Pro comes with both absolutely No-Ads as well as finally with Dark Mode, for a clean learning experience:
Once the early-adopter seats are all used, the price will go up and stay at $33/year.
Last updated: May 11, 2024
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.
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');
By default, data.sql scripts get executed before the Hibernate is initialized. We need Hibernate to create our tables before inserting the data into them. To achieve this, we need to defer the initialization of our data source. We’ll use the below property to achieve this:
spring.jpa.defer-datasource-initialization=true
When we run the project with this file on the classpath, Spring will pick it up and use it to populate the country table.
Please note that for any script-based initialization, i.e. inserting data via data.sql or creating schema via schema.sql (which we’ll learn next), we need to set the below property:
spring.sql.init.mode=always
For embedded databases such as H2, this is set to always by default.
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 USERS(
ID int not null AUTO_INCREMENT,
NAME varchar(100) not null,
STATUS int,
PRIMARY KEY ( ID )
);
Spring will pick this file up and use it for creating a schema.
When we run the project with this file on the classpath, we can see that even though the Users table is not present as an entity in our project, still Spring has created a Users table in our database by reading this schema.sql file.
Please note that if we are using script-based initialization, i.e. through schema.sql and data.sql and also Hibernate initialization, then using both of them together can cause some issues.
To solve this, we can disable the execution of DDL commands altogether by Hibernate, which Hibernate uses for the creation/updation of tables:
spring.jpa.hibernate.ddl-auto=none
This will ensure that only script-based schema generation is performed using schema.sql.
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 further data.sql is executed to populate the database.
Also, as explained in the previous section, 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 the official Spring documentation on initializing databases using SQL scripts.
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:
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.
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:
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.
Spring also provides the @Sql annotation – a declarative way to initialize and populate our test schema.
Here are the attributes of the @Sql annotation:
The @Sql annotation can be used at the class level or the method level.
The @Sql annotation can be declared at the class level to populate data for a test.
Let’s see how to use the @Sql annotation to create a new table and also load 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());
}
}
In the code above, we define two SQL scripts that execute before the test method. The @Sql declaration utilizes the default BEFORE_TEST_METHOD execution phase.
Spring version 6.1 and Spring Boot version 3.2.0 introduce class-level support for the executionPhase parameter with BEFORE_TEST_CLASS and AFTER_TEST_CLASS constants to determine if a script should run before or after the test class.
Let’s update the SpringBootInitialLoadIntegrationTest class and explicitly define an execution phase:
@Sql(scripts = {"/employees_schema.sql", "/import_employees.sql"}, executionPhase = BEFORE_TEST_CLASS)
public class SpringBootInitialLoadIntegrationTest {
// ...
}
Here, we run the SQL scripts before the test class by setting the value of the executionPhase to BEFORE_TEST_CLASS.
Furthermore, the AFTER_TEST_CLASS execution phase helps load a SQL script after a test class. This may be useful in a case where we want to clear the database after a test:
@Sql(scripts = {"/delete_employees_data.sql"}, executionPhase = AFTER_TEST_CLASS)
public class SpringBootInitialLoadIntegrationTest {
// ...
}
Notably, this configuration can’t be overridden by the method-level scripts and statements. Instead, the script will be executed in addition to the method-level scripts and statements.
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());
}
Here, the SQL script is executed before the execution of the test method.
Again, we can explicitly define the execution phase at the method level using the BEFORE_TEST_METHOD or AFTER_TEST_METHOD constants:
@Test
@Sql(scripts = {"/import_senior_employees.sql"}, executionPhase = BEFORE_TEST_METHOD)
public void testLoadDataForTestCase() {
assertEquals(5, employeeRepository.findAll().size());
}
The AFTER_TEST_METHOD execution phase helps to load a SQL script after the test method. We can use it, for example, to drop a database table after the execution of a test method.
By default, the @Sql annotation declaration at the method level overrides the @Sql declaration at the class level. In this case, the method-level @Sql declaration takes precedence over the SQL defined at the class level:
@Sql(scripts = {"/employees_schema.sql", "/import_employees.sql"})
public class SpringBootInitialLoadIntegrationTest {
@Autowired
private EmployeeRepository employeeRepository;
@Test
@Sql(scripts = {"/import_senior_employees.sql"})
public void testLoadDataForTestClass() {
assertEquals(5, employeeRepository.findAll().size());
}
}
Here, only import_seioner_employees.sql is executed when we run the test.
However, we can further configure this behavior using the @SqlMergeMode declaration which helps to merge method level @Sql declaration with class level @Sql declaration.
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:
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());
}
}
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.