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');
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.
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 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.
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.