CODEWITHSUNDEEP
databaseflyway
Joey Yi Zhao
Joey Yi Zhao

Reputation: 42604

Detected resolved migration not applied to database on flyway

We are using flyway to manage database schema version and we are facing a problem. Since we work as a team and use git as our source code management, there would be some cases that different people update database schema on their own local repo. If that happens, we will get

Detected resolved migration not applied to database: 2016.03.17.16.46"

The time "2016.03.17.16.46" was added by another person and I have already applied some timestamp later than that time. If that happens, we have to clean all database tables and create them again. We have tried to set false on validateOnMigrate and did flywayClean, but nothing help. Is there another way to change that?

Upvotes: 87

Views: 120333

Answers (11)

Goffee Chen
Goffee Chen

Reputation: 1

If you have permission to connect to the db. Find the table flyway_schema_history, and delete the corresponding row.

Upvotes: 0

jansmi
jansmi

Reputation: 1

Not really the answer to that particular case from the original question, but maybe this might also help somebody with similar error.

In my case the reason was different convention of file names. Normally we named the scripts something like VYYYYMMDDhhmmss__blah.sql, which is basically date and timestamp up to seconds. But then somebody introduced VYYYYMMDDhhmmssMS__blah.sql, so version is longer by two characters, meaning milliseconds.

After this format with MS was introduced, more files were uploaded in this convention, without anyone spotting it. But at some point I tried to put another migration in format without millis, and I faced the same error as in the original question.

I changed all the filenames to VYYYYMMDDhhmmss, but then I needed to update the flyway_schema_history table, to respect the changes, so make sure to update version and script columns. The checksums stay the same, since they're calculated only for the content.

Upvotes: 0

Sim0rn
Sim0rn

Reputation: 802

When using spring, the spring.flyway.out-of-order=true has been deprecated. You'll have to use the org.springframework.boot.autoconfigure.flyway.FlywayConfigurationCustomizer like e.g.:

public class FlywayConfiguration implements FlywayConfigurationCustomizer {
    @Override
    public void customize(FluentConfiguration configuration) {
        configuration
            .ignoreMigrationPatterns(
                "*:missing", //ignore applied database migrations missing in classpath with version number < latest migration
                "*:future" //ignore applied database migrations missing in classpath with version number > latest migration 
            )
            .outOfOrder(true);
    }
}

Upvotes: 0

NickEm
NickEm

Reputation: 81

Since spring.flyway.ignore-missing-migrations=true became deprecated. According to the docs I advise using spring.flyway.ignore-migration-patterns=*:missing. Or in the yaml:

spring:
  flyway:
    ignore-migration-patterns:
      - "*:missing"

Upvotes: 4

Piratenlulatsch
Piratenlulatsch

Reputation: 75

outOfOrder did not fix the problem for us.
Two migrations slipped into one deployment before it got removed. So we added those migrations back in and undid the changes in another migration.
Worked 🤷

Upvotes: 1

Alex
Alex

Reputation: 604

I faced similar problem when switching from one git branch to another and tried to run flyway:migrate. For example when I was on branch 'release_4.6.0' I didn't have migrations on my local machine from branch 'release_4.7.0' so I received next error FlywayException: Validate failed: Detected applied migration not resolved locally. The solution that worked for me is to set ignoreMissingMigrations flyway option to true. In maven it looks like

flyway:migrate -Dflyway.ignoreMissingMigrations=true

Maybe it's not an answer for this question, but it can be helpful for those who faced the same problem as me.

Here you can find more details: https://flywaydb.org/documentation/configuration/parameters/ignoreMissingMigrations

Upvotes: 43

codigoalvo
codigoalvo

Reputation: 1

In my case, there was existing a row with version 319 in database and the correponding file for 319 was renamed do 330, so the database registry could not find the corresponding file. Deleting the row from database solved the problem.

Upvotes: 0

azevik
azevik

Reputation: 161

You can also put it in your application.properties file if you want to apply the migrations when starting up the app:

spring.flyway.out-of-order=true

Upvotes: 13

nikiforovpizza
nikiforovpizza

Reputation: 576

In my case, I just renamed my migration file to some other name and then renamed it back – just to update modification date of the file. And it worked.

Upvotes: 0

Axel Fontaine
Axel Fontaine

Reputation: 35179

The migration option outOfOrder is your friend here. Set it to true to allow inserting those migrations after the fact.

On the command line, run:

flyway -outOfOrder=true migrate

Or if you use the Maven plugin:

mvn -Dflyway.outOfOrder=true flyway:migrate

Upvotes: 104

Harsh
Harsh

Reputation: 233

just add spring.flyway.ignore-missing-migrations=true to your properties file if you are using spring-boot.

This will ignore previous migrations.

Upvotes: 11

Related Questions