1.3.0 database: upgrade a 1.2.9 database on first start #124

Goal

An existing 1.2.9 database upgrades to 1.3.0 by starting 1.3.0. The operator backs up and starts the new version. Nothing else.

Why

1.3.0 replaces the old database history with one baseline. Running the baseline on a database that already has tables would fail, and replaying every 1.2.x step forever is how the copies drifted apart.

What changes

A small upgrade changelog ships in db/changelog/legacy/, next to the baseline, and runs first. It names the 1.2.9 starting point because that is the database it reads. Later upgrades (1.3.0 to 1.3.1, 1.4.0, and so on) need no special file. They run the release files in releases/ they have not run yet.

1. Version check. If the database is not empty and is not at 1.2.9, startup stops with a message saying "upgrade to 1.2.9 first". An empty database skips the check.
2. Bring data up to date. Add the code list values the code needs, matched by list name and value (never by ID). Mark them as system values. Add the four JDBC drivers as values an admin can delete. Update the ID counters for every table it touched.
3. Translations. New rows get their main text in the database's current default language. Translations are added only for other languages the database has. If the default is not one of the five shipped languages, the main text is English.
4. Schema changes 1.2.9 lacks. For example the Oracle time zone columns for service checks and the nullable service-check detail (the fix for sitmun-admin-app#516, pull request sitmun-backend-core#355).
5. Record the baseline as done. The baseline steps detect existing tables and are recorded without running. The 1.3.0 database tag is then recorded, as on a fresh install.

Languages are never added, removed, enabled, or disabled by the upgrade.

Supported starting points are PostgreSQL and Oracle installs from the production profiles at 1.2.9. Development databases are recreated.

Upgrade guide

Add docs/upgrade/1.2.9-to-1.3.0.md:

1. Back up the database.
2. If you are on an older 1.2.x, upgrade to 1.2.9 with the 1.2.9 release first. Known problem on that path: Oracle upgrade from 1.2.3: unique constraint violation on STM_TRANSLATION during MERGE in changeset 05_translations::5 #72.
3. Start 1.3.0 with the same database settings.
4. Check that /actuator/health is UP and that the admin code list screen shows application.type values ED and T.
5. What changes for you: code list values the code needs come back if they were deleted, JDBC drivers become deletable, translations for languages you removed are not recreated.

Done when

• CI restores a 1.2.9 PostgreSQL and a 1.2.9 Oracle database, starts 1.3.0, and the application is healthy.
• Starting 1.3.0 a second time changes nothing.
• A database at 1.2.8 stops with the "upgrade to 1.2.9 first" message.