I tried to update my (Oracle) database to Flyway 4.0 from Flyway 3.x today. I can see the update script tries to remove a couple of indexes (_vr_idx and _ir_idx). The problem I'm facing is the update has failed mid-way and now every time I rerun it, it complaints about the indexes not existing...
How do I proceed?
This is a known issue fixed in the upcoming Flyway 4.0.1.
In your case you have 3 options:
Drop the schema_version table and baseline the schema with Flyway 4.0
Manually perform the remaining actions on the schema_version table, followed by repair with Flyway 4.0
Recreate the dropped indexes and try again with Flyway 4.0.1
Related
I have recently started using the baseline and repeatable migrations in my app. Although I don't seem to be using any teams-edition features, yet flyway somehow switches automatically to the Teams edition instead of Community edition, and shows a message :
Flyway Teams Edition 8.2.0 by Redgate
Flyway Teams features are enabled by default for the next 27 days. Learn more at https://rd.gt/3A4IWym
Previously we had eight versioned migrations V1__xxxx.sql to V8__xxxx.sql
Now we have made the following changes :
All the eight migrations, plus some other init scripts have been combined into a single migration V1__seed-data.sql
Repeatable migrations have been put into R__xxxx.sql
Some placeholders have been placed into the flyway.conf like : fileflyway.placeholders.app_db_name=${APP_DB_NAME}
For our existing Production DB, which was already migrated till V8, we have Dropped the flyway_schema_history table and used the "flyway baseline" command with an environment variable FLYWAY_BASELINE_VERSION=1
After this, the flyway_schema_history shows us this result :
But after these changes, we are seeing the "Teams edition" message as above.
Earlier it used to show :
Flyway Community Edition 8.2.0 by Redgate
I am quite sure looking at the flyway documentation that we haven't used any Teams edition features. https://flywaydb.org/documentation/usage/commandline/baseline
Now I have 2 questions :
What caused flyway to switch to Teams edition without teams features being used?
What happens once the trial period ends? Does flyway block all our migrations in the future unless we buy the license?
Update Flyway to the latest version; the "Auto trial" feature created the "Teams edition" message you're seeing here, and was removed in Flyway 8.4.3 - release notes.
I changed a flyway script for error, and this brought my migrations to an error state (I have 5 script versions, but when I run my app it starts from the 4th, and get an error on 'reaction already exists').
I tried to use clean from flyway cli, but it didn't completely solve the problem... also, when I try pushing my branch to git, CI/CD pipeline will fail for the migration.
Since I'm in development environment, would it be a terrible idea to all delete migration scripts?
Would deleting all scripts allow me to 'start from scratch' in my development environment, or do I need to push the whole project again to avoid issues? (Project is not in production yet, I don't really need flyway migrations)
Depending on which flyway version you are using, one option is to go to the flyway_schema_history or schema_version table and just locate the row (corresponding to the failed script) and change the success column to true or 1. Then manually run the script (the correct one) against DB.
Background
I am running a flyway migration against DB2 using the command line interface. I have done a number of tests and all works fine. I added in some commands to cause a failure.
Question
Can someone confirm if alter table, drop table or create table SHOULD be rolled back if the migration fails and the database supports DDL? When i test it it looks like an alter table add column statement was not rolled back after a failure in the same flyway script.
Ok so i checked the flyway website and found a list of supported drivers and versions where DDL is supported. It seems like the version of DB2 we are using is below this threshold. Based on that i guess the execution of migrate script is not bound in a single transaction and that is why i am seeing some changes remaining that were applied before the script failure.
I am currently using Flyway version 1.7. I read in the release notes that Flyway 2.0 comes with a new metadata table format and all 2.x versions do an automatic upgrade on first run. All fine so far. But what if I have to rollback my application and downgrade Flyway back to 1.7? Will the old Flyway work with the new metadata format? Is there a rollback script to get the old metadata table format back?
I am using PostgreSQL as database engine.
No, it's a one-way upgrade. It does run within a transaction though, so in the very unlikely event it would fail, the transaction would be rolled back.
Just want to know whoever is working with flyway if they are getting this
<< Flyway Schema Creation >>
with version set to 0.
It suddenly started appearing on my metadata table and I am not sure where it came from and how I can run mugrates without it appearing again
This means flyway created the schema(s) you specified in flyway.schemas. Calling clean() will also drop the schemas themselves and not just the objects they contain.