Stage 5 · L54

Evolve the schema without losing existing facts

Core · original Session 5

Native checkpoint 05

Use the starter for this stage's focused examples. The cumulative transfer and solution belong at the stage-end capstone. Baseline checks pass; transfer checks initially fail. Downloads contain the matching native starter and solution for this stage.

Stage 05 adds Equipment.condition so maintenance can block new reservations. Existing equipment rows need a valid value; changing the model alone would not update PostgreSQL. Migration0002 adds the non-null column with temporary default available, so existing catalogue facts are backfilled.

The migration then installs a CHECK allowing available or maintenance and removes the temporary server default. Future application inserts choose the value through the ORM's explicit default. A direct SQL insert that omits condition now fails instead of quietly choosing a business state. This distinction makes the backfill policy and future-write policy visible.

The test creates a separate owned schema inside the disposable fixture database, upgrades only to0001, inserts an existing equipment row, then upgrades to head. It confirms the original name survives with condition available and revision0002. It also checks that omitting condition via direct SQL fails after the default is removed. The schema is dropped in finally; no existing database is touched.

A real deployment would also need compatibility planning for old app writers, migration timing, backup verification and rollback behavior. This local snapshot tests the forward data transformation only. It deliberately refuses destructive downgrade and does not claim the live website or its learner records received any migration.

0001: existing catalogue fact; 0002: add condition default available; Existing rows gain available; Install state CHECK constraint; Remove temporary server default

Follow the running code

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 05

Add condition with a temporary available backfill default
Preserve existing equipment rows and identities
Constrain allowed condition values
Remove the temporary default for future explicit writes
Record Alembic revision0002.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

Read the explanation and predict the focused example’s outcome.
Explain the before/after row and why a default used for backfill may be removed. Compare upgrade with model editing.
Compare the observed outcome with the focused answer and state its boundary.

Expected: The existing Before item keeps its ID/name/stock and gains condition=available. The reviewed forward migration changes stored schema and records0002. Removing the temporary default makes later raw SQL supply a deliberate value; a Python model edit alone would leave the database unchanged. Use the separate stage capstone for the already-taught nested-page transfer.

Model-only edits fail against old tables; dropping a backfill default changes old-writer compatibility.

Focused exercise and answer

Complete this focused exercise before reading its answer. The full native transfer is introduced only at the end of the stage.

Your transfer task: Explain the before/after row and why a default used for backfill may be removed. Compare upgrade with model editing.

Explain the before/after row and why a default used for backfill may be removed. Compare upgrade with model editing.

Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

The existing Before item keeps its ID/name/stock and gains condition=available. The reviewed forward migration changes stored schema and records0002. Removing the temporary default makes later raw SQL supply a deliberate value; a Python model edit alone would leave the database unchanged. Use the separate stage capstone for the already-taught nested-page transfer.

Stage 05 capstone — after these prerequisites

Implement status-filtered, ordered/bounded nested rental DTO page with deliberate eager load and one SELECT.

Use the downloaded starter after completing this stage's focused exercises. The cumulative implementation below is a stage transfer answer, not an answer to an earlier lesson.

python run_checks.py --stage 05 --role starter --prepare
python run_checks.py --stage 05 --role starter
python run_checks.py --stage 05 --role starter --transfer

From this extracted starter: preparation and baseline pass; transfer initially fails only at the named unfinished target. After implementing it, rerun the same starter --transfer command and expect success.

Optional comparison in a separate solution directory

Optional comparison: download and extract this stage’s solution ZIP into a separate directory. Change your terminal into that extracted solution root (beside checkpoint.json and run_checks.py) before running the following commands. Your starter remains a starter even after you implement its task.

python run_checks.py --stage 05 --role solution --transfer

Inspect the cumulative capstone implementation

def list_rentals(session, status, limit, offset):
    statement = select(Rental).options(joinedload(Rental.equipment))
    if status is not None:
        statement = statement.where(Rental.status == status)
    statement = statement.order_by(Rental.created_at, Rental.id).limit(limit).offset(offset)
    return [RentalDetail.model_validate(row) for row in session.scalars(statement).all()]

Check your reasoning

Does a passing migration fixture authorize deployment?

Show the explanation

No. It establishes the local forward transformation; production compatibility, backup and release approval remain separate.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.