PH1.2 — Schema 0003: planning tables and typed mapped classes #10

Closed
opened 2026-09-11 09:02:09 +00:00 by bart · 2 comments
Collaborator

Parent

Row PH1.2 in docs/12-implementation-plan.md (branch, owned paths and doc section are defined there).

What to build

Migration 0003 creates the planning and execution tables (solver_run, plan_version, plan_version_date, assignment, unassigned_job, plan_lock, validation_finding, service_feedback, reliability_score, notification) with all indexes from docs/08-data-model.md, plus typed mapped classes. Schema is complete after this ticket.

Acceptance criteria

  • alembic upgrade head then downgrade -1 round-trips cleanly on a real Postgres
  • Every table, column, constraint and index in docs/08-data-model.md for these aggregates exists
  • Append-only tables have no update/delete path in the mapped classes; mapped classes pass mypy --strict
  • The full chain base → head → base migrates cleanly

Blocked by

  • #9 — Schema 0002: master data tables and typed mapped classes
## Parent Row **PH1.2** in `docs/12-implementation-plan.md` (branch, owned paths and doc section are defined there). ## What to build Migration `0003` creates the planning and execution tables (solver_run, plan_version, plan_version_date, assignment, unassigned_job, plan_lock, validation_finding, service_feedback, reliability_score, notification) with all indexes from docs/08-data-model.md, plus typed mapped classes. Schema is complete after this ticket. ## Acceptance criteria - [x] `alembic upgrade head` then `downgrade -1` round-trips cleanly on a real Postgres - [x] Every table, column, constraint and index in docs/08-data-model.md for these aggregates exists - [x] Append-only tables have no update/delete path in the mapped classes; mapped classes pass `mypy --strict` - [x] The full chain `base → head → base` migrates cleanly ## Blocked by - #9 — Schema 0002: master data tables and typed mapped classes
Owner

Starting PH1.2 (schema 0003: planning tables and typed mapped classes).

Branch: feature/db-schema-planning (from main, which already has 0002_master_data_tables.py).
Owned paths: backend/alembic/versions/**, backend/src/polaris/db/models/**.

Will build migration 0003 for solver_run, plan_version, plan_version_date, assignment, unassigned_job, plan_lock, validation_finding, service_feedback, reliability_score, notification per docs/08-data-model.md, plus matching typed SQLAlchemy mapped classes following the _mixins.py/_types.py/_enum.py pattern from PH1.1.

Starting PH1.2 (schema 0003: planning tables and typed mapped classes). Branch: `feature/db-schema-planning` (from `main`, which already has `0002_master_data_tables.py`). Owned paths: `backend/alembic/versions/**`, `backend/src/polaris/db/models/**`. Will build migration `0003` for solver_run, plan_version, plan_version_date, assignment, unassigned_job, plan_lock, validation_finding, service_feedback, reliability_score, notification per docs/08-data-model.md, plus matching typed SQLAlchemy mapped classes following the `_mixins.py`/`_types.py`/`_enum.py` pattern from PH1.1.
Owner

PR opened: #66 (feature/db-schema-planning -> main). All four acceptance criteria ticked above.

Verified against a real postgis/postgis:17-3.4 container (testcontainers): alembic upgrade head / downgrade -1 / upgrade +1 round-trip cleanly, and the full chain base -> head -> base migrates cleanly. mypy --strict and ruff clean; full backend suite green.

One seam note: fixing this ticket's own point (creating solver_run) broke a pre-existing PH6.6 test that asserted /metrics omits solver_run lines while the table doesn't exist. Fixed directly in the PR (mirroring PH1.1's #57 precedent) rather than leave a regression; traceability issue at #67. api/metrics.py itself needed no change.

PR opened: https://git.xor.nu/patrick/Polaris/pulls/66 (`feature/db-schema-planning` -> `main`). All four acceptance criteria ticked above. Verified against a real `postgis/postgis:17-3.4` container (testcontainers): `alembic upgrade head` / `downgrade -1` / `upgrade +1` round-trip cleanly, and the full chain `base -> head -> base` migrates cleanly. `mypy --strict` and `ruff` clean; full backend suite green. One seam note: fixing this ticket's own point (creating `solver_run`) broke a pre-existing PH6.6 test that asserted `/metrics` omits `solver_run` lines while the table doesn't exist. Fixed directly in the PR (mirroring PH1.1's #57 precedent) rather than leave a regression; traceability issue at #67. `api/metrics.py` itself needed no change.
patrick self-assigned this 2026-09-11 11:44:44 +00:00
bart closed this issue 2026-09-11 12:04:48 +00:00
Sign in to join this conversation.
No labels
ready-for-agent
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
patrick/Polaris#10
No description provided.