Menu
I'm using flyway with gradle, I've ran one of the migrations manually inside the database console, I want to run flyway, but tell it to ignore one specific migration version in between all the others. Can this be done ?
475
it means that you ran migrate before and it failed at 1.0 for some reason. You need to identify why the previous migration failed at 1.0 and solve it if you have already not done so. Once solved you need to run flyway repair to tell flyway that whatever failed is now out of the way. Then run flyway migrate again.
Repeatable migrations are very useful for managing database objects whose definition can then simply be maintained in a single file in version control. Instead of being run just once, they are (re-)applied every time their checksum changes. They are typically used for. (Re-)creating views/procedures/functions/packages/ ...
Flyway does not handle implicity committed statements when flyway process crashes. Bookmark this question.
While both tools are based on Martin Fowler's Evolutionary Database, there are many differences in what these tools offer. Here's where Liquibase and Flyway differ. The bottom line is that Liquibase is more powerful and flexible — covering more database change and deployment use cases than Flyway.
1) Run flywayMigrate, let the migration fail. 2) Manually, update the flyway meta table (success column) for that specific version of migration. 3) Run flywayMigrate again.
This is where skipExecutingMigrations comes in. On prod instead of running a normal migrate, instead run migrate -skipExecutingMigrations=true. Now Flyway will not actually try to execute the contents of the migration on this environment, instead just updating the schema history to say it’s been applied.
Here are some thoughts about how to get database migration right. Flyway tries to enforce incremental database changes. That means we shouldn’t update already applied migrations, except repeatable ones. By default, we should use versioned migrations that will only be run once and will be skipped in subsequent migrations.
The solution I've seen for this (in general, with migrations, not specific to Flyway which I have no idea what it is) is to have "reverse migrations" that must be applied down downgrading. @torek, But it worked fine with older version of Flyway.
You would have to hack it a bit to get it to work, so I don't recommend this approach, but it would work in a pinch.
I've only tested this with Maven, but I'm pretty sure it'd work with Gradle too.
Migrate up until the version before the one you applied manually
# Assuming you applied 01.002 manually
$ mvn flyway:migrate -Dflyway.target=01.001
Insert a row for the script you applied
-- Make sure these vals closely replicate those from other rows
insert into schema_version( installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success)
values ( 2, '01.002', 'static_data', 'SQL', 'V01/V01.002__static_data.sql', null, 'username', current_timestamp, 0, true );
Repair the schema_version checksum
$ mvn flyway:repair
Apply the other migrations
$ mvn flyway:migrate -Dflyway.validateOnMigrate=false -Dflyway.outOfOrder=true
The two -D properties there may not be necessary, depending on whether you got the insert correct or not. Flyway may disagree with your script description, for example, even if the checksum is now correct.
140
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
