F-r-ldraledigplannerare/backend/migrations/versions/010_drop_pinned_and_exclusion.py

"""Drop planned_leave_day.is_pinned and planned_day_exclusion — restructure step 3b.

Step 3a (migration 009) added `day_assertion` as an additive, reversible
replacement for both: a pinned `planned_leave_day` row, an ad-hoc row
(`wish_id IS NULL`), and a `planned_day_exclusion` row. Step 3b moved every
reader and writer onto `day_assertion` (see `AllocationInputLoader`,
`PlanningService.pinned_keys`/`sync_plan`, `DayAssertionService`) and deleted
the `/api/planned-days` write endpoints and the `/api/planned-day-exclusions`
router entirely — nothing reads either dropped column/table any more.

`planned_leave_day` is now purely derived output: no `is_pinned` column,
its ONE writer is `sync_plan`/`DayAssertionService`'s mirroring. SQLite
(3.35+, in use here) supports `ALTER TABLE ... DROP COLUMN` directly for a
column with no index/CHECK constraint referencing it, which `is_pinned`
never had.

Must stay in step with `app/db/connection.py`'s `_FULL_SCHEMA` —
`tests/integration/test_schema_parity.py` asserts exactly that.

Revision ID: 010
Revises: 009
Create Date: 2026-09-20
"""

from __future__ import annotations

from alembic import op

revision: str = "010"
down_revision: str | None = "009"
branch_labels: str | None = None
depends_on: str | None = None

_EXCLUSION_TABLE_DDL = """
CREATE TABLE IF NOT EXISTS planned_day_exclusion (
    id TEXT PRIMARY KEY,
    workspace_id TEXT NOT NULL,
    child_id TEXT NOT NULL,
    parent_personal_data_uuid TEXT NOT NULL,
    date DATE NOT NULL,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL,
    UNIQUE(workspace_id, child_id, parent_personal_data_uuid, date),
    FOREIGN KEY (workspace_id) REFERENCES workspace(id) ON DELETE CASCADE,
    FOREIGN KEY (child_id) REFERENCES child(id) ON DELETE CASCADE,
    FOREIGN KEY (parent_personal_data_uuid) REFERENCES personal_data(uuid) ON DELETE CASCADE
)
"""

_EXCLUSION_INDEX_DDL = """
CREATE INDEX IF NOT EXISTS idx_planned_day_exclusion_workspace
    ON planned_day_exclusion (workspace_id)
"""


def upgrade() -> None:
    op.execute("DROP INDEX IF EXISTS idx_planned_day_exclusion_workspace")
    op.execute("DROP TABLE IF EXISTS planned_day_exclusion")
    op.execute("ALTER TABLE planned_leave_day DROP COLUMN is_pinned")


def downgrade() -> None:
    """Recreate `is_pinned`/`planned_day_exclusion`, reconstructed from
    `day_assertion` — which still holds every fact at this point, since this
    migration is the only one that ever drops the legacy shapes, and it does
    so on `upgrade()`, not here. (009's `downgrade()`, which runs *after*
    this one on a `downgrade` past 010, is what finally drops `day_assertion`
    itself — see that migration's docstring for the point past which nothing
    is recoverable.)

    Reconstruction, not just DDL:
    - a `day_assertion` row with a concrete `day_type`
      (`sjukpenning`/`lagsta`/`vacation`) sets `is_pinned = 1` on the
      `planned_leave_day` row at the same natural key (workspace_id,
      child_id, parent_personal_data_uuid, date).
    - a `day_assertion` row with `day_type = 'none'` becomes a
      `planned_day_exclusion` row at that key, reusing the assertion's own
      id/timestamps (they're 1:1, and an id only needs to be unique within
      its own table).

    Two ways this is honestly NOT a lossless round trip:
    - A concrete assertion with no matching `planned_leave_day` row (an
      ad-hoc/pinned day whose mirrored row was since deleted, e.g.
      re-derived away by a later plan sync) has nothing to set `is_pinned`
      on. The `UPDATE` below simply matches zero rows for it — the fact
      is not an error, just unrepresentable in the pre-009 schema. (009's
      `downgrade()` warns about exactly this before it drops the table
      that's the last place the fact exists.)
    - `day_assertion` never recorded *why* a row was a concrete assertion —
      pinned, ad-hoc (`wish_id IS NULL`), or both; 009's own upgrade
      backfill already conflates them (`WHERE is_pinned = 1 OR wish_id IS
      NULL`). So a row that was ad-hoc but never pinned comes back with
      `is_pinned = 1` instead of its original `0` — over-restored, not
      under-restored, and only for rows already exempt from the allocator
      via `wish_id IS NULL`.
    - A row that was pinned AND later collided with an exclusion at the
      same key before 009's upgrade ran: 009's `INSERT OR REPLACE` already
      kept only the `'none'` assertion (exclusion wins — see 009's
      docstring). That pinned fact was discarded at upgrade time, long
      before this downgrade runs; there is no assertion left to recover it
      from. The exclusion itself, however, round-trips correctly.
    """
    op.execute("ALTER TABLE planned_leave_day ADD COLUMN is_pinned INTEGER NOT NULL DEFAULT 0")
    op.execute(_EXCLUSION_TABLE_DDL)
    op.execute(_EXCLUSION_INDEX_DDL)

    from sqlalchemy import text

    conn = op.get_bind()

    # Concrete assertions -> re-pin the matching planned_leave_day row, if
    # one still exists at that natural key (see docstring: if not, there is
    # nothing to pin, and that's fine).
    conn.execute(
        text(
            "UPDATE planned_leave_day SET is_pinned = 1 "
            "WHERE (workspace_id, child_id, parent_personal_data_uuid, date) IN ("
            "  SELECT workspace_id, child_id, parent_personal_data_uuid, date "
            "  FROM day_assertion WHERE day_type != 'none'"
            ")"
        )
    )

    # 'none' assertions -> recreate the exclusion rows they replaced.
    conn.execute(
        text(
            "INSERT INTO planned_day_exclusion "
            "(id, workspace_id, child_id, parent_personal_data_uuid, date, "
            " created_at, updated_at) "
            "SELECT id, workspace_id, child_id, parent_personal_data_uuid, date, "
            " created_at, updated_at "
            "FROM day_assertion WHERE day_type = 'none'"
        )
    )