You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flyway allows the following defaults to be changed:
sqlMigrationPrefix, default 'V'
repeatableSqlMigrationPrefix, default 'R'
sqlMigrationSeparator, default '__'
sqlMigrationSuffix, default '.sql'
... the question is whether this flexibility actually brings much benefit in comparison to the increase in complexity (or greater chance of confusion).
(It's also a validation nightmare - choosing the wrong values could break a migration or, worse, cause the wrong components to be identified and the wrong action to occur: 'V1.0__schema.sql' with a separator of '__' is clear, but with a separator of '.' becomes a placeholder/migration schema from V1 to V0__schema, which is still (almost) valid)
The text was updated successfully, but these errors were encountered:
Flyway allows the following defaults to be changed:
sqlMigrationPrefix
, default 'V'repeatableSqlMigrationPrefix
, default 'R'sqlMigrationSeparator
, default '__'sqlMigrationSuffix
, default '.sql'... the question is whether this flexibility actually brings much benefit in comparison to the increase in complexity (or greater chance of confusion).
(It's also a validation nightmare - choosing the wrong values could break a migration or, worse, cause the wrong components to be identified and the wrong action to occur: 'V1.0__schema.sql' with a separator of '__' is clear, but with a separator of '.' becomes a placeholder/migration schema from
V1
toV0__schema
, which is still (almost) valid)The text was updated successfully, but these errors were encountered: