Spring sometimes makes it hard to follow best practices. In particular, new features may not be production-ready yet, or lack functionality that is crucial for the given situation.
Due to Spring’s long history,1 there is also much outdated documentation (like this post, a year from now ;-) while the documentation of current features may still be incomplete.2 This makes it hard to decide when to use a Spring feature, and when to skip it.
One example for this are Spring Data JPA’s repository populators, which allow to initialize a JPA data source from a JSON file.3 This is particularly useful for integration testing and has several advantages, for example:
Maintainability, because JSON is well-known and typically easy to read.
Independence of the underlying database technology (as the populators are based on JPA).
Independence of the JPA implementation (haven’t tested that yet).
However, here’s the catch: you will need some extra code to support the definition of object references! Object references typically end up as foreign keys in the database, so many non-trivial database schemata are not supported out of the box.
At the same time, Hibernate allows you to specify SQL scripts for database initialization via its
hibernate.hbm2ddl.import_files configuration file property. This solution seems less general, but good enough for setting up test databases:
SQL is a well-known language, too, so the SQL scripts should be as easy to maintain as a JSON-based initialization.
Initialization scripts for test databases will typically consist of
INSERT statements only, which should be easy to port to other SQL dialects.
On top of that, SQL is much more powerful: in case you also need to include views, stored procedures, or triggers, you don’t have to adjust any code for database initialization.
TL;DR: Use JPA populators with JSON files to initialize simple (single table) test databases, otherwise let your JPA implementation import SQL files instead.