Feature: Support for baseline migrations

[dennisvang]

It would be great if flamingock could support baseline migrations, or something similar.

The flyway docs explain the concept of baseline migrations more clearly than I ever could:

Over the lifetime of a project, many database objects may be created and destroyed across many migrations which leaves behind a lengthy history of migrations that need to be applied in order to bring a new environment up to speed.

Instead, you might wish to add a single, cumulative migration that represents the state of your database after all of those migrations have been applied without disrupting existing environments.

Flyway gives you a way to achieve this using Baseline Migrations.

[...]

[dieppa]

Hello @dennisvang ,

Thanks for raising this. I think this is a valid use case and aligns well with the Flyway baseline migration concept.

Just to make sure we are aligned, my understanding of the expected behaviour would be something like this:

• A baseline migration would be a special kind of migration/change unit that represents the cumulative state of the target system up to a given version/order.
• For a fresh environment with no Flamingock history, Flamingock could execute the latest applicable baseline migration and then continue with the regular migrations after that point.
• For an environment that already has Flamingock history, the baseline migration should be ignored, so it does not disrupt existing environments.
• The baseline migration would be created by the user, just like any other migration. Flamingock would provide the runtime behaviour around selecting it, applying it, and skipping the migrations covered by it.

For example, if we had:

V001
V002
V003
B003
V004
V005

Then a fresh environment could execute:

B003
V004
V005

Whereas an existing environment that already applied V001, V002, and V003 would ignore B003 and only continue with V004 and V005.

I think the important part would be defining the exact semantics around selection and safety. For example, if an environment already has some historical migrations applied, we should probably avoid applying a baseline automatically, as mixing both paths could be dangerous.

Does this match the behaviour you had in mind?

[dennisvang]

Hi @dieppa thanks for picking this up.
Your description aligns perfectly with the behaviour I had in mind.

The baseline migration would be created by the user, just like any other migration. [...]

I guess it would probably be quite complicated to auto-generate the baseline migration, although that would be a very nice feature to have. Reminds me of Django's squashed migrations.

[dieppa]

Thanks, that makes sense.

To better understand the value of this feature, could you share a bit more about the problem you're trying to solve?

For example, is the main motivation to simplify onboarding of new environments, reduce the number of historical migrations that need to be executed, or something else?

I'm trying to understand the underlying use case so we can evaluate whether a dedicated baseline migration concept is the right solution, or whether the same goal could already be achieved through existing migration patterns.