2
votes

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

  1. Delete the test data
  2. 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.

1

1 Answers

2
votes

Repair is your best bet. Empty those data migrations and run the repair command to have their checksums recalculated based on the empty files.