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

Flyway repair command repeatedly fixes the repeatable migration rows in the FLYWAY_SCHEMA_HISTORY table #2821

Closed
zjwu2000 opened this issue May 19, 2020 · 2 comments
Assignees
Milestone

Comments

@zjwu2000
Copy link

@zjwu2000 zjwu2000 commented May 19, 2020

Which version and edition of Flyway are you using?

version 6.3.0

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)
Yes, the 6.4.1 has the same issue.

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

Command-line

Which database are you using (type & version)?

Snowflake 4.16

Which operating system are you using?

Windows 10 Enterprise

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.)
run flyway repair command

flyway -configFiles=.\flyway.conf repair

What did you expect to see?

After run the Flyway migration successfully, the Flyway repair command should not repair anything.

What did you see instead?

The Flyway repair command repeatedly repairs the rows in the FLYWAY_SCHEMA_HISTORY table that have NULL value in ‘Version’ column; since the repeatable migration scripts don’t have version, the version column is always NULL, which will make the "repair" command always repair the repeatable migration script rows in each run.

The old version 6.2.2 I used didn't have this issue. I tested version 6.3.0, it has the same issue. I am not sure 6.2.3 and 6.2.4.

Below is the sample output from 'repair' command:

Database: jdbc❄️//loandepot.east-us-2.azure.snowflakecomputing.com:443/ (Snowflake 4.16)
Repair of failed migration in Schema History table "FLYWAY"."FLYWAY_SCHEMA_HISTORY" not necessary. No failed migration detected.
Repairing Schema History table for version null (Description: Function COMMON.JS FACTORIAL, Type: SQL, Checksum: -1351863153) ...
Repairing Schema History table for version null (Description: Function COMMON.JS FACTORIAL, Type: SQL, Checksum: -1351863153) ...
Repairing Schema History table for version null (Description: Procedure DEMO.SP ASSOCIATE UPSERT, Type: SQL, Checksum: 72741172) ...
Repairing Schema History table for version null (Description: Seeding COMMON.STATECODE, Type: SQL, Checksum: -135004093) ...
Repairing Schema History table for version null (Description: VIEW DEMO.VW ASSOCIATE STATELICENSE, Type: SQL, Checksum: -1713403746) ...
Repairing Schema History table for version null (Description: Function COMMON.JS FACTORIAL, Type: SQL, Checksum: -1351863153) ...
Repairing Schema History table for version null (Description: Function COMMON.JS FACTORIAL, Type: SQL, Checksum: -1351863153) ...
Repairing Schema History table for version null (Description: Function COMMON.JS FACTORIAL, Type: SQL, Checksum: -1351863153) ...
Successfully repaired schema history table "FLYWAY"."FLYWAY_SCHEMA_HISTORY" (execution time 00:19.188s).
Manual cleanup of the remaining effects the failed migration may still be required.

@zjwu2000 zjwu2000 changed the title Flyway repair command repeatedly fix the repeatable migrations rows in the FLYWAY_SCHEMA_HISTORY table Flyway repair command repeatedly fixes the repeatable migration rows in the FLYWAY_SCHEMA_HISTORY table May 19, 2020
@juliahayward juliahayward self-assigned this May 21, 2020
@juliahayward
Copy link
Member

@juliahayward juliahayward commented May 21, 2020

There was a change at 6.3.0 where the checksums of repeatable migrations are calculated after placeholder replacement (so that they re-run when your placeholder values change). However, there's a bug where repeatable migrations that don't have placeholders have their checksums updated to the same value on repair unnecessarily.

It's harmless in the sense that it won't result in anything being done incorrectly, just a small amount of wasted work, and will be fixed in the next patch version.

@Lyeeedar
Copy link
Contributor

@Lyeeedar Lyeeedar commented May 27, 2020

Fixed by 95dbab8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants