Stage 3 · L16

Trace validated input into a row and back into a response

Core · original Session 3

Follow one complete vertical slice before introducing layers. A client POSTs JSON; FastAPI constructs EquipmentIn; create_equipment constructs an Equipment row from those validated fields; session.add/flush writes within a transaction; EquipmentOut validates the scalar row representation; session.commit makes it durable; the handler returns 201 and Location.

This sequence makes the boundaries observable. At the API boundary, invalid input never enters the write handler. At the database boundary, a duplicate name can fail even when input validation succeeds. At the output boundary, the public schema selects and validates the result. At the transaction boundary, commit happens before success. A fresh-session GET confirms the claimed stored effect.

Keep model_dump limited to the declared input schema. The extra-field rule means a caller cannot set an id or later private role by adding JSON keys. That is useful defense at the data boundary, but it is not authentication or authorization. The current training create routes remain intentionally unauthenticated until the identity stages.

The customer transfer repeats this sequence with a different identity type and resource. Use User(email=payload.email), flush its generated UUID, create CustomerOut, commit, set Location and read it by UUID. Preserve 409/422/404 failure behavior and never add login semantics. The solution is exactly these two handlers; it does not solve a later registration/verification task for you.

Stage 04 will move the write decision and commit into a service and queries into a repository without changing this public behavior. First prove this simple slice works. Refactoring an untested request→row→response flow would make it difficult to tell whether an error came from architecture changes or from the original contract.

Request CustomerIn → add User profile → flush identity
→ validate CustomerOut → successful commit → 201/Location
Next GET → a new owned session reads the committed profile.

Pydantic accepts only the public input contract; User stores the profile; flush obtains the generated UUID within the transaction; CustomerOut validates public output before successful commit. 201/Location follows completion, and a later GET must read through another session. This is a profile, not a login account. Implement the full customer slice only in the stage capstone.

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

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

@app.post("/customers", status_code=201, response_model=CustomerOut)
def create_customer(payload: CustomerIn, response: Response, session=Depends(session_dependency, scope="function")):
    row = User(email=payload.email)
    session.add(row)
    session.flush()
    output = CustomerOut.model_validate(row)
    session.commit()
    response.headers["Location"] = f"/customers/{output.id}"
    return output


@app.get("/customers/{customer_id}", response_model=CustomerOut)
def get_customer(customer_id: UUID, session=Depends(session_dependency, scope="function")):
    row = session.get(User, customer_id)
    if row is None:
        raise HTTPException(404, detail="Customer not found")
    return row