When developing a spring boot application, we enabled flyway for data migration. For testing purpose, we want to wipe out the database before running each test class. But, the flyway doesn't automatically clean database by default. Instead, we have to set cleanDisabled to be false explicitly. And then, the tests are passed, so I'm guessing somehow spring boot sets cleanDisabled to be true? Thanks for investigation!
Comment From: philwebb
We don't set cleanDisabled to true as far as I can tell. That looks like a property that was introduced in Flyway 4 which we won't officially support until Spring Boot 2.0.
Have you tried setting a breakpoint on the setCleanDisabled property to see what's calling it? Do you have a sample application that you can share so that we can investigate?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
Comment From: FyiurAmron
FWIW, @philwebb , based on https://github.com/flyway/flyway/issues/3407 , it seems that the default for regular Flyway is now true, and that can probably propagate into Spring Boot settings. Bumping Flyway certainly made my tests crash due to
org.flywaydb.core.api.FlywayException: Unable to execute clean as it has been disabled with the 'flyway.cleanDisabled' property.
- so if Spring Boot uses the default Flyway settings as the "default" defaults, I'd say it's true by default now (at least that's what my debugger shows with flyway = "9.19.3" and org.flywaydb.flyway-test-extensions:flyway-spring-test:9.5.0)
Comment From: wilkinsona
The default changed in Flyway 9 and we have already adapted to that change in Spring Boot 3.0.
Comment From: FyiurAmron
@wilkinsona true, I'm still using 2.7.x so I guess that's why I stumbled upon this. Good to know that it's already been taken care of and thanks for the clarification & source link!