Skip to content

feat(adapters): implement baseline on Flyway + Alembic adapters#166

Open
antonyprasad-db wants to merge 1 commit into
databricks-solutions:mainfrom
antonyprasad-db:feat/adapter-baseline-stamp
Open

feat(adapters): implement baseline on Flyway + Alembic adapters#166
antonyprasad-db wants to merge 1 commit into
databricks-solutions:mainfrom
antonyprasad-db:feat/adapter-baseline-stamp

Conversation

@antonyprasad-db

Copy link
Copy Markdown

What

Implements the optional baseline() capability on the Flyway and Alembic adapters. The SchemaMigrationAdapter contract (ADR-0005) has always declared baseline?(), but every built-in adapter omitted it (flagged as a deferred follow-up slice in both adapter files).

  • FlywayAdapter.baseline → new baselineFlyway runner (flyway baseline -baselineVersion=<v> [-baselineDescription=<d>]).
  • AlembicAdapter.baseline → new stampAlembic runner (alembic stamp <rev>), Alembic's equivalent operation. The contract's version field carries the target revision.

Both stamp an already-populated schema at a version so pre-baseline migrations are treated as applied and never re-run — the adoption path for a database whose schema predates the migration tool.

Why

Closes the two // baseline intentionally absent … deferred to a follow-up TODOs. Additive and backward-compatible: callers property-check adapter.baseline before invoking, so anything treating it as absent is unaffected. apply/status/rollback runner behavior is unchanged.

Testing

  • Tier 1 (hermetic, npm test): ✅ 2408 passed, 0 failed. Updated the Flyway + Alembic adapter contract tests (static surface now asserts baseline is present).
  • npm run typecheck: ✅ clean.
  • Tier 3 (live): ⚠️ not run — I don't have a billable Lakebase workspace wired for the integration suite in this environment. Live baseline/stamp behavior is not exercised by an automated run here; the change mirrors the existing apply/status runner+adapter pattern (same DSN seam, same error shape). Flagging per CONTRIBUTING so a reviewer with workspace access can green Tier 3, or advise if you'd like a live-integration assertion added for baseline.

Notes

  • Follows the repo convention that feature PRs don't include rebuilt dist/ (shipped separately in build:/release: commits).
  • No CLI subcommand added — that's slice 4 per ADR-0005. This PR is the adapter+runner capability only.

The SchemaMigrationAdapter contract (ADR-0005) declares an optional
baseline() capability, but every built-in adapter omitted it. Implement
it on both:

- FlywayAdapter.baseline wraps a new baselineFlyway runner
  (flyway baseline -baselineVersion=<v> [-baselineDescription=<d>]).
- AlembicAdapter.baseline wraps a new stampAlembic runner
  (alembic stamp <rev>), Alembic's equivalent operation; the contract's
  version field carries the target revision.

Both stamp an already-populated schema at a version so pre-baseline
migrations are treated as applied and never re-run - the adoption path
for a database whose schema predates the migration tool.

Additive and backward-compatible: callers property-check adapter.baseline
before invoking, so nothing that treated it as absent breaks. Runner
behavior for apply/status/rollback is unchanged.

Contract tests updated (static surface now asserts baseline is present);
live apply/baseline behavior remains covered by the env-gated
integration suites.

Co-authored-by: Isaac
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant