diff --git a/docs/day2/upgrade.rst b/docs/day2/upgrade.rst index d7ec206b..11c614d8 100644 --- a/docs/day2/upgrade.rst +++ b/docs/day2/upgrade.rst @@ -63,3 +63,53 @@ a similar project named `Imago `_ to sync your This works independently from your ``imagePullPolicy`` by using the ``sha256`` image checksum in background. + + + +Flyway Database Migration Issues +-------------------------------- +When using a custom version of Dataverse (e. g. when you maintain a small +fork and deploy it based on images of this project), you might run into a +situation where deployments fail due to "out of order" migrations. + +When deploying, `Flyway `_ takes care of maintaining +the database tables to be inline with the object-relational mapping. +Backporting or adding a custom change might leave you in a state where +Flyway complains about migrations not being applicable because newer migrations +already happened. The deployment will fail for good. + +To solve this situation, you need to apply the migrations "out of order". +Add the Flyway plugin to ``pom.xml`` (when you maintain a fork, this should +be pretty clear where to do this). + +.. code-block:: xml + + + org.flywaydb + flyway-maven-plugin + ${flyway.version} + + jdbc:postgresql://localhost/dataverse + dataverse + YOUR DATABASE PASSWORD HERE + + + + org.postgresql + postgresql + 42.2.12 + + + + +Now forward your PostgreSQL server to ``localhost`` (keep it running): + +.. code-block:: shell + + kubectl port-forward service/postgresql 5432 + +And then apply the migrations out of order: + +.. code-block:: shell + + mvn -Dflyway.outOfOrder=true flyway:migrate