d458ed1b34
All sibling services on the box manage schema with Alembic (async env, `alembic upgrade head` in the compose command). matchmaking-v2 was the outlier (Base.metadata.create_all + no migration for the new user_feed.exhausted_at column). Bring it onto the pattern: - alembic.ini + alembic/env.py (async, URL from settings.DATABASE_URL, target = Base.metadata) + script.py.mako — copied/adapted from user-service. - versions/0001_baseline: the current prod schema (user_feed WITHOUT exhausted_at + opportunity_state). - versions/0002_pool_and_exhausted: CREATE user_job_pool + ADD user_feed.exhausted_at (additive). - Dockerfile: COPY alembic.ini + alembic/. requirements: alembic>=1.13.0. Verified both paths: fresh DB → upgrade head builds all 3 tables; prod-like (existing tables+data) → stamp 0001 → upgrade runs ONLY 0002, existing rows survive. 64 tests pass. PROD ADOPTION (one-time): `alembic stamp 0001_baseline` on RDS before the first deploy, then the compose's `alembic upgrade head` applies 0002.
25 lines
593 B
Mako
25 lines
593 B
Mako
"""${message}
|
|
|
|
Revision ID: ${up_revision}
|
|
Revises: ${down_revision | comma,n}
|
|
Create Date: ${create_date}
|
|
"""
|
|
from typing import Sequence, Union
|
|
|
|
from alembic import op
|
|
import sqlalchemy as sa
|
|
${imports if imports else ""}
|
|
|
|
revision: str = ${repr(up_revision)}
|
|
down_revision: Union[str, None] = ${repr(down_revision)}
|
|
branch_labels: Union[str, Sequence[str], None] = ${repr(branch_labels)}
|
|
depends_on: Union[str, Sequence[str], None] = ${repr(depends_on)}
|
|
|
|
|
|
def upgrade() -> None:
|
|
${upgrades if upgrades else "pass"}
|
|
|
|
|
|
def downgrade() -> None:
|
|
${downgrades if downgrades else "pass"}
|
|
|