Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatch between validate's fail-fast and repair's broad-brush #2116

Closed
eepstein opened this issue Aug 26, 2018 · 2 comments

Comments

@eepstein
Copy link

@eepstein eepstein commented Aug 26, 2018

Which version and edition of Flyway are you using?

5.1.4

If this is not the latest version, can you reproduce the issue with the latest one as well?

(Many bugs are fixed in newer releases and upgrading will often resolve the issue)

N/A - this is the latest release

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

Maven plugin

Which database are you using (type & version)?

Postgresql 9.6

Which operating system are you using?

MacOS and Ubuntu

What did you do?

(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

First : we touched two of the .sql migration files,
Then:
mvn -Dflyway.configFiles=config/flyway-stage.conf flyway:validate

What did you expect to see?

Both validations fail.

What did you see instead?

Only the first change was reported as a validation failure.
This is validate's fail-fast policy, which would be fine,

EXCEPT

the repair function does not take a parameter to indicate the specific migration to repair (update the checksum in the db in this case).

instead repair happily updated all the checksums, which combined with validate's fail-fast logic means that we had no idea someone had touched one of the other .sql file in the migration folder.

Holy DB mess batman.

@axelfontaine axelfontaine added this to the Flyway 5.2.0 milestone Aug 27, 2018
@axelfontaine axelfontaine changed the title Catastrophic mismatch between validate's fail-fast and repair's broad-brush Mismatch between validate's fail-fast and repair's broad-brush Feb 11, 2019
@juliahayward

This comment has been minimized.

Copy link
Member

@juliahayward juliahayward commented Sep 12, 2019

As repair doesn't (currently) offer an option to repair only up to a certain point, the obvious change is to make validate() report all validation failures. This also will not change existing behaviour, except that people who currently see validation failure messages could potentially see longer ones.

@juliahayward

This comment has been minimized.

Copy link
Member

@juliahayward juliahayward commented Sep 13, 2019

In 6.0.3 and higher, validate() will provide all failures. If finer grained control is required, we can add options to both validate() and repair() to only go up to a specific migration - please kick off a new issue if that's the case.

juliahayward added a commit that referenced this issue Sep 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.