2

I'm wondering, how is it possible to make Flyway baseline and outOfOrder work together?

The outOfOrder flag can be used when you are working with branches, so if steps appear in the "past" they are not set to "Ignored" but they are executed after they appear. For example if they are arriving with a branch.

I.e. a database has steps 1.0, 1.1, 1.2 and there is a cherry picked 2.2 patch to it. Then 2.0 and 2.1 comes with the regular release, but they are <2.2, so you have to use outOfOrder to install those.

The problem comes when a new database is created on the branch that contains 1.0, 1.1, 1.2 and 2.2, and a baseline is added. Now, baseline tells Flyway to SKIP everything before. So when 2.0 and 2.1 comes they are skipped, they are not even tagged as Ignored, they automatically become part of the baseline.

So what I'm thinking about is that maybe instead of baseline being an almighty step, it should be instead "fake success"-es on the currently known installations steps. Is there a better way, or how to such a thing?

N. Labrahmi
  • 657
  • 4
  • 23
Alluir
  • 61
  • 6
  • Why has the baseline been added in your scenario? My understanding of this is that if you use baseline you accept that no scripts prior to the baseline version will need to be run. – David Atkinson Apr 09 '18 at 14:19
  • What is the way to tell a newly created schema which steps are considered already executed? I had the impression that is the baseline. – Alluir Apr 09 '18 at 15:09
  • Can't you create this new schema by running flyway -target=n migrate so that its version history table will be correct? – David Atkinson Apr 09 '18 at 19:46
  • Hmm, that would work if 1.0 would be a complete create script. However 1.0 is a script, only after the project started to use Flyway, so it contains changes only from a certain point, it cannot be used to create a schema. But you are right, in a best of worlds that's how it should be done, unfortunately not in this setup. Probably we will aim for that in later projects, at least, I'll try to navigate in that direction :). – Alluir Apr 10 '18 at 05:53
  • Yesterday I tested this method: https://stackoverflow.com/questions/29012034/how-to-skip-a-specific-migration-with-flyway and it works surprisingly well. Apparently, for Flyway to work properly only 3 of the fields have to be meaningful: installed_rank, version and success. Repair can fill in the rest from the steps. – Alluir Apr 10 '18 at 05:57
  • If you added script V0.1 to your set of migration scripts, that took the database to v1.0, then you'd have a complete set of migration scripts that can build a database from scratch. If you have a database at v1 you can script this out using SQL Developer, for example. – David Atkinson Apr 10 '18 at 09:20
  • But the method you link to is interesting. Thanks for linking to this. It feels a little hacky, but pretty clever. I might experiment with this myself as I have a few scenarios that aren't as clean as I'd have hoped. – David Atkinson Apr 10 '18 at 09:21

0 Answers0