Flyway or the highway!
Flyway is a great tool to manage the consistency of your database in Java-land. For each change in the database schema that is needed to run your application consistently with the db, you place a sql file in the db.migration folder. This allows flyway to manage the migration. Flyway checks if the sql files are already executed (using a hash table in the target database), else it will run the neccessary sql script(s).
There is however a little setup required, even within a Spring Boot application.
You can use the maven flyway plugin to run flyway migrations with mvn over CLI. This would mean decoupling a major part of your database's consistency management from your application into a build script...
Though the only thing a Spring Boot application actually needs, is the flyway-core dependency (which is recommended by Spring). Keeping the management within the application. Probably the right choice since in this case the db only exists by the authority of that application.
The first rule is to just let Spring Boot decide upon the necessary version of Flyway. The latest shiny version of Flyway doesn't not work out of the box at this point in time. I'm using Spring Boot 2.1.6 which sings together with Flyway 5.2.4 (instead of current shiny 6.1.4) .
At the current stage of the application we'd let hibernate generate the db schema. But we're heading to a serious test phase soon. In the new setup hibernate no longer generates the schema, but is still allowed to validate the database schema in comparison to the data structure between the entities in in
This is even dubbed by some as best practice.
So hibernate had to relinquish some of it's control. The (enum) property spring.jpa.hibernate.ddl-auto is used to configure hibernates control on the database. [note: ddl apparently stands for Data definition language, used to define data structures especially database schemas.] This property is now set to "validate".
The only other config were a few properties in the end:
Don't forget to change up the config for your test profile if you're using in memory H2 for testing:
There is however a little setup required, even within a Spring Boot application.
You can use the maven flyway plugin to run flyway migrations with mvn over CLI. This would mean decoupling a major part of your database's consistency management from your application into a build script...
Though the only thing a Spring Boot application actually needs, is the flyway-core dependency (which is recommended by Spring). Keeping the management within the application. Probably the right choice since in this case the db only exists by the authority of that application.
The first rule is to just let Spring Boot decide upon the necessary version of Flyway. The latest shiny version of Flyway doesn't not work out of the box at this point in time. I'm using Spring Boot 2.1.6 which sings together with Flyway 5.2.4 (instead of current shiny 6.1.4) .
At the current stage of the application we'd let hibernate generate the db schema. But we're heading to a serious test phase soon. In the new setup hibernate no longer generates the schema, but is still allowed to validate the database schema in comparison to the data structure between the entities in in
This is even dubbed by some as best practice.
So hibernate had to relinquish some of it's control. The (enum) property spring.jpa.hibernate.ddl-auto is used to configure hibernates control on the database. [note: ddl apparently stands for Data definition language, used to define data structures especially database schemas.] This property is now set to "validate".
The only other config were a few properties in the end:
spring.flyway.enabled=truespring.flyway.url=jdbc:postgresql://localhost:5432/mydbspring.flyway.user=secret_user
spring.flyway.password=secret_password
Don't forget to change up the config for your test profile if you're using in memory H2 for testing:
# hibernate + h2spring.jpa.hibernate.ddl-auto=create-dropspring.flyway.enabled=false
Comments
Post a Comment