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
Copy file name to clipboardExpand all lines: spring-modulith-runtime/src/main/java/org/springframework/modulith/runtime/flyway/SpringModulithFlywayMigrationStrategy.java
Copy file name to clipboardExpand all lines: spring-modulith-runtime/src/test/java/org/springframework/modulith/runtime/flyway/SpringModulithFlywayCustomizerUnitTests.java
+30-23Lines changed: 30 additions & 23 deletions
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,9 @@ public class SpringModulithFlywayCustomizerUnitTests {
Copy file name to clipboardExpand all lines: src/docs/antora/modules/ROOT/pages/runtime.adoc
+9-3Lines changed: 9 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,8 +113,14 @@ As of Spring Modulith 2.0, we support the execution of module-specific https://d
113
113
Application modules are encouraged to define migrations for their own persistent data only, which means that these migrations have to be executed in the order of the module dependency tree.
114
114
115
115
Assume a default Flyway setup with migrations located in `classpath:db/migration`, two application modules `first` and `second` (with `second` depending on `first`), and an activated `spring.modulith.runtime.flyway-enabled` xref:appendix.adoc#configuration-properties[configuration property].
116
-
With that in place we will augment the configured migration to run the default one first, followed by one for `classpath:db/migration/first` and one for `classpath:db/migration/second`.
117
116
118
-
By selecting which folder to place the migration files in, you can differentiate migrations always to be run from ones that will only get executed for the corresponding module. The application module test integration will only execute the default migration and the ones for modules included in the test run.
117
+
With that in place we will customize the Flyway setup as follows:
118
+
119
+
- The root migration folder will be changed to `db/migration/__root`. For that, the default version tracking table will be used.
120
+
- Additional migrations for `db/migration/${moduleIdentifier}` will be registered with a tracking table of `flyway_schema_history_${moduleIdentifier}`.
121
+
These migrations are also set up to a baseline version of 0 and set up to baseline on migrate.
122
+
- Migration locations ending in a wildcard will not be customized.
119
123
120
-
We will not augment migration runs including wildcard expressions in the migration location definition.
124
+
Note, that he version numbers used in migration scripts are now effectively scoped to the application module and should not use global ordering.
125
+
126
+
By selecting which folder to place the migration files in, you can differentiate migrations always to be run from ones that will only get executed for the corresponding module. The application module test integration will only execute the default migration and the ones for modules included in the test run.
0 commit comments