3.15.1 One-time prep before the first auto-migrator deploy ¶

The auto-migrator starts up by creating a db_version bookkeeping table and, in later phases, by ALTER TABLE-ing memories. Neither works with only the original grants from sql/001_init.sql. Apply the additional privileges once:

# /root cannot be read by the postgres user, so pipe via stdin
cat sql/migrator_prep.sql | sudo -u postgres psql -d ownsona

The script:

• GRANT CREATE ON SCHEMA public TO ownsona;
• ALTER TABLE memories OWNER TO ownsona; (and its sequence)
• prints a verification block showing can_create_in_public = t and memories_owner = ownsona. If you don’t see those, the grants didn’t apply.

The script is idempotent — safe to re-run.

3.15.2 Deploying the new WAR ¶

After the prep runs (or if it was already in place), upgrade deploys follow the normal “build ⇒ swap WAR ⇒ restart Tomcat” pattern documented in OwnSona-rollout-plan.md. The auto-migrator runs at servlet load and brings the database up to whatever CURRENT_DB_VERSION the new WAR is built against; you can verify in journalctl -u ownsona.service:

... migrator: db_version baseline established (version=1)
... migrator: applied v=2 name="add record_version column" ms=...
... record_migrator: done upgraded=0 failed=0

If the migrator fails (typically: permission errors or a registry mismatch), the servlet refuses to load and the failure shows in the journal. Fix the underlying issue and redeploy — the database is in its pre-migration state because each migration runs in its own transaction.

3.15.3 Rollback ¶

Roll back the WAR by restoring the previous Kiss.war. Migrations in the rollout plan are strictly additive, so the older code simply ignores the newer columns. If you also want to remove newly-created columns or the db_version row that recorded a specific migration, run the rollback SQL listed in the corresponding phase’s ship checklist in OwnSona-rollout-plan.md.