You cannot have migration scrtipts with the same version number as you will get:
Found more than one migration with version 'x.y.z' (Offenders: SQL ...)
Here is a workaround I suggest: multiple developers are working on the same version, say 1.0
but on different features. I guess you are using some issue tracker that adds ids to each issue, like FOO-16
. When a developer works on that issue, the migration script is called V1.0.16__my_greatest_feature.sql
. This way (assuming each feature/branch has its own issue) there are no collisions.
Also I am assuming that database migration scripts are independnt and non-overlapping, but if this is not the case you'll have problems while merging everything to a stable release.
So in a stable release you have several migration scripts with gaps, e.g: V1.0.16
, V1.0.27
, V1.0.101
(if FOO-16
, FOO-27
and FOO-101
were chosen) - Flyway won't care. All the features that didn't make it to a stable release 1.0
(e.g. V1.0.35
) should be renamed to target next major release (e.g. V1.1.35
).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…