ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema¶
- Status: accepted
- Date: 2026-06-04
- Deciders: Nicolas Burri (delegated detail decision, reviewed via commit)
Context¶
PostgreSQL/jOOQ is constrained (arc42 §2.1). Open: how the schema evolves (migration tool) and how jOOQ classes are generated. The schema carries compliance-relevant invariants (scope checks, later RLS policies), so generated code drifting from the real schema would be a correctness risk.
Options Considered¶
- Flyway (chosen): plain-SQL migrations — the full PostgreSQL feature set (RLS
policies, comments, check constraints) is expressible verbatim; pinned by the Quarkus
BOM (
quarkus-flyway); SQL files double as readable schema documentation. - Liquibase: changelog abstraction adds a layer between us and PostgreSQL-specific features we need (RLS); no benefit for a single-database product.
- jOOQ DDLDatabase (codegen by parsing SQL files): no container needed, but its SQL parser does not cover everything PostgreSQL accepts (e.g. policies) — exactly the features this project relies on.
Decision¶
- Flyway with plain-SQL migrations in
backend/persistence(src/main/resources/db/migration); applied at application start (quarkus.flyway.migrate-at-start) and identically in tests. - jOOQ codegen against the real migrated schema: the build (
GenerateJooqTaskinbuildSrc) starts a throwaway Testcontainers PostgreSQL (same image as everywhere:postgres:18-alpine), applies all Flyway migrations, and runs the jOOQKotlinGenerator. Generated classes can therefore never drift from what migrations actually produce. backend/persistenceis the technical home of migrations and generated classes; it exposes the jOOQ API to domain modules (documented in arc42 §5).
Consequences¶
- Docker is a build-time dependency (already required for tests).
- The PostgreSQL version is pinned in one place per concern (build: persistence
build file; runtime dev services: api
application.properties) — keep aligned. - Schema review = SQL review: migrations are plain, diffable SQL files referencing the requirements they implement.
- Version alignment rule: Flyway/driver/Testcontainers versions follow the Quarkus BOM pins (noted in the version catalog).