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.
Related
I'm using EF Core Migrations in my .NET Core projects, and deploy using DevOps pipelines.
In my build pipeline, I build a migration SQL script using a Command Line task to execute a dotnet ef migrations script command (using the --idempotent option), then execute it in the release pipeline using an Azure SQL Database deployment task. All fairly standard, to judge from a simple google search (eg. here), which is how I learned of the approach in the first place.
This is my problem: To achieve certain desired results, in some of my migrations I use Custom Migration Operations (migrationBuilder.Sql("...")) to execute some hand-crafted SQL as part of a migration.
However, as the project develops, and my DB schema changes over time, older such migrations inevitably contain SQL which no longer fits the schema. One would think this isn't a problem, as any migration is meant to be applied to a database with some specific schema version only. However, as it turns out, the dotnet ef migrations script command builds a SQL script with a bunch of conditional SQL block like this:
IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20190123160628_SomeMigrationId')
BEGIN
/* Generated or custom SQL here */
END;
Note: every migration is included in the script, and the IF NOT EXIST-clauses ensure that only the not-yet-applied ones are executed in the database.
However, the custom migration task SQL statements are included as-is in the script, and if they are outdated, they longer compile. Then the DB deployment task fails, as does the whole deployment.
Has anyone else had and solved this problem, or know another way to deploy migrations which doesn't have this issue? It seems to me this seriously affects the utility of the MigrationBuilder.Sql() command, which is the only way to arbitrarily "massage" data as part of a migration.
I'm using flyway for migrations. Flyway version is Flyway 3.2.1 by Boxfuse. When I am executing
./flyway migrate -url=jdbc:postgresql://$FLYWAY_DATABASE_HOST/$FLYWAY_DATABASE_NAME -password=$FLYWAY_DATABASE_PASSWORD -user=$FLYWAY_DATABASE_USER
I'm getting following error
"ERROR: Validate failed. Migration Checksum mismatch for migration 80
Applied to database : -401430104
Resolved locally : -485639995
How can I resolve this?
Migration Checksum mismatch means that the contents of a particular migration file has changed since you executed it, and that means that your script collection might not be a faithful representation of the database schema.
If you are happy that the scripts are still good (eg the changes were comments and formatting) then flyway repair with the same URL and credentials will clear this error. If not, then you should either revert the changes, or flyway repair and accept the mismatch.
My current project has a few Flyway migrations in place that are used to import initial data into a database. This data is convenient especially for developers to be able to quickly setup the project. Production data is imported through some batch jobs and has a newer version.
Some of these migrations are quite big (~20MB) and so everytime the application starts, Flyway takes some time to calculate the checksum of the migrations. This also is a problem for integration tests as they also take longer because of this.
I consider this approach to be a misuse of Flyway, I think migration tools should be used mainly for structural data.
I want to remove those files from our application and rather use a configuration management tool (e.g. Vagrant, Puppet, Chef) to import test data on developer environments. However, I can't just delete the migration files from the application as Flyway will complain that a migration has been recorded in the database but is not present in the application migrations.
My first thinking was to create a new migration with a high-priority version number that will
Delete the test data
Delete the migration from the schema_version table
and then remove the migration scripts. This however does not work, Flyway still complains that the removed migration script is missing.
Is there a restriction that you cannot interact with the schema_version table in migrations?
What other options do I have? If at all possible I want to do this using Flyway and not manually.
Repair is your best bet. Empty those data migrations and run the repair command to have their checksums recalculated based on the empty files.
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
I am new to Flyway and I am using Flyway 2.1 code base for migration and execution of SQL statements on a previous schema version using Flyway. Once i execute my newer SQL statements the version entry in the metadata table is incremented.
But before I migrate my new version of the schema (i.e before I migrate/ execute the newer SQL statements on the database schema), I would like to capture all the new SQLs in another preview.sql file, so that the DBAs can see the SQLs before they proceed with the migrate.
I plan to do this by adding a flyway.preview() method to the Flyway.java file. Could you please let me know what other files would need to be changed to accomplish this?
Also, I only want to do this if the new version is > current schema version currently in the database. I checked the 2.1 code but the SchemaVersion class has been deprecated in 2.1 and I am not sure how to obtain the current version from the database.
I would appreciate your help or any suggestions that would correct my approach.
Thank you
The necessary abstractions are not in place yet to support this, but I plan on adding them over the next few weeks to support batch updates in 2.2. Once that is done, it should be much easier to implement this.
As for querying the state of the DB, you have the Flyway.info() to assist you.