Repeatable migrations

[dlight]

Flyway features repeatable migrations for defining objects in the db that can simply be tracked as is from the source code (typically because they are stateless, like CREATE OR REPLACE ...). This pattern is a good way to manage functions, stored procedures, etc: it enables having the previous version of the function/stored procedure/etc on Git history, while keeping only the last version checked out, like most source code, making it easier to track changes within a single function.

This question on stack overflow, linking to this Flyway github issue, and this other issue motivates it further.

[jakajancar]

One potential danger with this is if such views/functions/... are used in the migrations themselves. This can lead to making the migrations historically changeable, and the end state depend on timing of deploys.

For example, depending if you if you apply:

• Scenario A:
  1. Code v10: Migration v10, functions/views/... v10
  2. Code v11: Migration v11, functions/views/... v11
• Scenario B:
  1. Code v11: Migration v10 & v11, functions v11

You will get different results, because in scenario B migration v10 did not have access to DB functions/views/... from v10.