I have flyway integrated in one of my projects. I have many migrations and it takes a long time to migrate a new empty database, mainly because there are seed data added along the way as well. Now I want to change that. Unfortunately those migrations were already pushed to production (and yes, at some point the seed data was migrated there as well).
My idea was to set a baseline for the current version of the production system and clean up the old migrations afterwards: Squash the schema-migrations and move the seed- and test-data to a new location, that is not deployed to production.
Now my questions are:
flyway baseline ...
on the database directly? Or can I use any kind of special migration file? Maybe write the baseline line directly to the schema_version
table of the database? How would such a query look like?V4_6_3__...
. So my baseline needs to be on V5__...
? Or is V4__...
enough and all migrations with the same major version are included?Sorry for the basic questions, but it seems to me, that the flyway documentation is no help at all...
Thanks in advance!
Baseline is for introducing Flyway to existing databases by baselining them at a specific version. This will cause Migrate to ignore all migrations up to and including the baseline version. Newer migrations will then be applied as usual.
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes. This is very useful for managing database objects whose definition can then simply be maintained in a single file in version control.
They are in the format s3:<bucket>(/optionalfolder/subfolder) . To use AWS S3, the AWS SDK v2 and dependencies must be included, and configured for your S3 account. Flyway Community is limited to a maximum of 100 migrations in Amazon S3.
Sry for the late answer. I have done a pretty similar thing to the one @markdsievers suggested:
I assured that the production environment was at least on version X
(flyway.setTarget(X)
). Then I changed to a new schema version table (flyway.setTable('temporary_schema_version')
) and ran a single migration, that deleted the old table. Afterwards I changed the schema version table back to the original one, set a baseline to version Y > X
and ran another migration that deleted the temporary table.
Now I can edit/squash/delete all migrations with a version lower than Y
without crashing my production-deployment.
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