Repository navigation
Flyway migration generation regressed: ADR-0015 removed the meta:migrate --flyway mojo and the shared-engine Flyway output adapter was never built #192
Description
Activity
- added 8 commits that reference this issue
on Aug 2, 2026 The ADR-0015 Flyway-prefix output adapter is built and on
main(c504c982,058ce03f,36928ff6,6b670c2b). CI green.Usage
meta migrate --db "$DB_URL" --dialect postgres --migration-format flyway --slug add_program_view # -> src/main/resources/db/migration/V4__add_program_view.sql # -> src/main/resources/db/migration/U4__add_program_view.sql
Also settable once as
migrate.formatin.metaobjects/config.jsonso a JVM shop never passes the flag.Design — a third output adapter beside the homegrown and D1/Wrangler layouts, exactly the slot ADR-0015 §3 specified. The diff/emit engine is untouched: it already produces the up/down SQL, and an adapter only chooses the envelope.
- Versioning is scan-and-increment on the highest
V<N>__, as the removed mojo did (4ca10dd2), so it composes with migrations already in the directory. A dotted version (V10.5__) increments on its leading integer, and theU__files it emits do not bump the counter. - Undo is emitted as
U<N>__, Flyway's own convention. Undo is a paid edition feature and Community ignoresU__files rather than failing, so they are inert-but-correct there and become live on Teams/Enterprise. - Output dir defaults to
src/main/resources/db/migration;--out-diroverrides. - Flyway owns apply.
--apply,apply-pendingand--rollbackare refused under this format, each naming the Flyway command instead — writing behind Flyway desyncsflyway_schema_history.--dialect d1with it is refused too.
Two notes on the issue text. The flag is
--migration-format, not--format: that name is already the global output-rendering flag (toon/json/text). And the issue's second half — themeta initscaffold telling Flyway adopters to "apply schema only throughmeta migrate" — was already fixed in PR #263, so this covers the adapter only.Gates — the real-engine round-trip this repo requires of every migrate change:
V1__init.sqlapplies to a real sqlite database, and a second migrate against the migrated DB reports no changes and writes noV2__(convergence); then a field is added,V2__is emitted past the existingV1__, applies, and the column is present. Plus adapter unit tests (9), CLI refusal + precedence tests, and a no-churn assertion that default-format output is unchanged. migrate-ts 697 / cli 432 / workspace build + typecheck all green.Design and plan:
docs/superpowers/specs/2026-08-04-issue-192-flyway-output-adapter-design.md,docs/superpowers/plans/2026-08-04-issue-192-flyway-output-adapter.md. Documented indocs/features/cli.md.Unreleased — ships in the next npm cut (
migrate-ts+cli+sdk); seeCHANGELOG.md[Unreleased]. The other three ADR-0015 adapters (two-file, dbmate/goose divider, Liquibase) stay deliberately unbuilt — they become mechanical now the format axis exists.- Versioning is scan-and-increment on the highest
- added a commit that references this issue
on Sep 1, 2026
Summary
metaobjects once shipped Flyway-named migration generation for JVM consumers (the Java
meta:migrate --flywayMaven mojo, plugin v7.0.0). ADR-0015 consolidated all migration onto the shared TS engine and removed that mojo, designating a "Flyway-prefix output adapter" on the shared engine as its replacement — but that adapter was never built.Net effect: a Spring-Boot-Kotlin + Exposed + Flyway consumer today has no supported path to generate migrations from metadata. Yet the generated
meta initagent-context (.metaobjects/AGENTS.md) still instructs adopters to "never hand-write SQL … apply schema only throughmeta migrate" — advice that is impossible to follow on a Flyway stack, because there is nometa migrateoutput that Flyway can consume. This misdirects adopters (human and agent) and forces hand-authoredV<n>__*.sqlthat only a boot-time drift-gate keeps honest.How it regressed
MetaDataMigrateMojogained a Flyway-naming option in4ca10dd2("feat(maven-plugin): meta:migrate Flyway-naming option for codegen-kotlin consumers"), shipped in Java plugin 7.0.0 (itsplugin.xmllists amigrategoal). Design of record:docs/superpowers/specs/2026-05-25-codegen-kotlin-design.md§5.1 —<flyway>true</flyway>→ scanflywayDirfor the highestV<N>__, increment, emitV<N+1>__<slug>.sql.77a5c46a("refactor(omdb)!: remove meta:migrate goal + Java migration-conformance scenarios") removed the mojo and the Java migrate engine behind it, per ADR-0015 (single shared migrate engine). ADR-0015 §3 explicitly designates Flyway-prefix (V__/U__) as reference output adapter fix(cli): scaffold outDir defaults to src/generated, not ./src/db #1 and notes the prior Flyway-emit groundwork "should inform the shared adapter."server/typescript/packages/migrate-ts/srchas zeroflywayreferences.meta migrateemits only its own<seq>-<slug>/up.sql+down.sqllayout plus a private ledger table — incompatible with a Flywayflyway_schema_historyboot without an adapter.Impact on JVM/Flyway consumers
generate, verify, docs, editor, help— nomigrate. The TS CLI's output layout can't feed Flyway. So metadata → Flyway migration must be hand-authored to match codegen — the exact thing the doctrine says never to do.meta initemits.metaobjects/AGENTS.mdwith "never hand-write SQL … apply schema only throughmeta migrate." On a Flyway stack there is no such command, so an agent/dev following the scaffold hunts for tooling that does not exist. (This recently cost a real multi-file investigation for one such consumer before the removal history was uncovered.)Proposed fix
nextFlywayVersionscanner from4ca10dd2is prior art). EmitV<N+1>__<slug>.sqlinto a configurableflywayDir, diffing the offline snapshot (meta migrate baseline --from-dbseeds it once). Prove emitted-DDL fidelity against thecodegen-kotlinExposed table shapes viameta verify --db. Note the known gaps the engine does not yet model (triggers, cross-column CHECKs, function-valued defaults, GIN array indexes) will still require some hand-authored SQL — the adapter should degrade gracefully, not silently drop them.meta initscaffold so a Flyway-configured consumer's generated.metaobjects/AGENTS.mddoes not claimmeta migrateis the schema-apply path. For a Flyway stack it should state that migrations are hand-authored to match codegen and enforced by the boot-time table/DB drift-gate (meta verify --db) — or at minimum not assert a command that isn't shipped for that stack.Evidence (all in this repo)
spec/decisions/ADR-0015-single-shared-migrate-engine.md(§3 output-adapter design; Flyway-prefix reference; build path pending)git show 4ca10dd2(added Flyway option) /git show 77a5c46a(removed the goal)docs/superpowers/specs/2026-05-25-codegen-kotlin-design.md§5.1flywayreferences anywhere underserver/typescript/packages/migrate-ts/src