I'm trying to add Flyway to a Spring Boot project. In accordance with the instructions, I've created my initial DDL script and committed it to src/main/resources/db/migration/V1__base_version.sql.
If I run the baseline command, this will create the flyway_schema_history table and set the baseline version therein to 1.
While this works fine for my local database, I would like this to happen automatically on the other developers' local environments, UAT environment, etc.
I tried adding the following property to the Spring Boot config
spring:
flyway:
baseline-on-migrate: true
I expected this to do the same thing as the baseline command when the Spring Boot app starts up if the flyway_schema_history table does not exist, i.e. create this table and insert a row specifying the current schema version, but it didn't.
Is there a way to automatically baseline the database when the app starts up?
Related
I am trying to create a small Spring Boot setup with a h2 database.
Now I have a weird problem, which I can't solve.
If I don't create an data.sql for initial data, the app starts fine and creates my entity tables.
If I create an data.sql for initial data and keep the existing table from previous step, everything works fine.
If I create an data.sql for initial data and remove my existing h2 file, I get the error that it can't import the data, because the table is missing.
How do I tell Spring to create my tables before importing the initial data?
This is covered in the release notes for Spring Boot 2.5:
By default, data.sql scripts are now run before Hibernate is initialized. This aligns the behavior of basic script-based initialization with that of Flyway and Liquibase. If you want to use data.sql to populate a schema created by Hibernate, set spring.jpa.defer-datasource-initialization to true. While mixing database initialization technologies is not recommended, this will also allow you to use a schema.sql script to build upon a Hibernate-created schema before it’s populated via data.sql.
I have a spring-boot application with PostgreSQL. Some of the tables are created using models and other tables have to be created prior to the start of the application or while starting the application. That can be done by running an SQL file while startup.
But DB tend to change over time, we may have to alter some of the tables, add some new tables without disturbing the existing data in the tables, etc.
Is there a way to add new SQL files, and run only the SQL files which was not run in spring-boot application each time when we rebuild and rerun? And don't run any of the SQL files while start-up if everything were already executed?
For your scenario liquibase is the best solution. You can merge liquibase on your spring boot application.
Ex: https://javadeveloperzone.com/spring-boot/spring-boot-liquibase-example/
You can use flyway. It allows you to have versioned sql scripts:
flywaydb.org
flywaydb spring boot plugin
Examples:
Spring Boot Database Migrations with Flyway
Incrementally changing your db with java and flyway
I'm working on a spring boot application that uses Camunda
I've just bumped our Camunda version by a couple of minor versions, and I'm running incremental SQL scripts with Flyway to update the DB to support the new camunda version (v1.02--7.8-7.9.sql and v1.03--7.9>7.10.sql)
This migration works fine on existing databases that are currently on Camunda 7.8, but it fails when I try to run the application on a clean database.
One of the scripts tries to add a column:
ALTER TABLE ACT_ID_USER
ADD LOCK_EXP_TIME_ timestamp;
But, if the application is running on a clean database, it will complain that the column is already present - presumably because the database has just been initialised with 9.10, so running a 9.8 migration after the fact doesn't work
I'm wondering if there's a way for Flyway to not run those migrations, if the database is empty on startup?
Or, is my problem the way I'm using Flyway? Should flyway be getting executed before Camunda initialises the Database?
I am trying to integrate flyway to my existing Spring boot app. My requirement is, the default table created by flyway needs to be created on different DB schema and my applications actual table migration must happen on different schema. Reason being, no addition table must be created on the applications DB schema. Currently we are using Mysql
We had a Spring Boot app with the flyway configuration in application.properties file for different environments:
flyway.enabled=true
flyway.url=jdbc:postgresql://localhost:5432/finance
flyway.schemas=user
flyway.password=password
flyway.user=postgres
flyway.baseline-on-migrate=true
We had the application-dev.properties, application-local.properties and application-aws.properties with the configuration specific to the environment
Flyway provides a property flyway.schemas. When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first schema of the list.
https://flywaydb.org/documentation/commandline/migrate.html
ex:flyway.schemas=schema1,schema2,schema3
I am trying to setup two different database with Flyway 5.0.7, MySQL for development and H2 for testing. I have configured both databases in respective files.
For Development, src/main/resource/application.properties
spring.datasource.url=jdbc:mysql://localhost:3306/moment
spring.datasource.username=root
spring.datasource.password=root
flyway.locations=db/migration,db/specific/mysql
For Testing, src/test/resource/application.properties
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:db;DB_CLOSE_DELAY=-1
spring.datasource.username=sa
spring.datasource.password=sa
flyway.locations=db/migration,db/specific/h2
Below is the folder structure for Flyway migration files
In this case Flyway is not able to find migration files under specific folder and throws error when applying V1.1__Insert_Records.sql for table not found.
If I move the specific folder inside db/migration, I am getting error for duplicate files of same version.
Any suggestions how should I configure migration files for multiple databases to work with Flyway?
I suspect you might be using Spring Boot 2.x here? If so, flyway.locations is no longer valid and will be ignored.
Flyway will then just use the default location (db/migration), which will find only the V1.1__Insert_Records.sql script but not the V1__Create_table.sql script.
With Spring Boot 2.x, flyway.locations must be prefixed with spring.:
spring.flyway.locations=db/migration,db/specific/h2
By the way, if you use the {vendor} placeholder in the location, Spring Boot will work out the directory from the lowercase of the database driver id (h2, mysql, oracle, etc), which is nice:
spring.flyway.locations=db/migration,db/specific/{vendor}