Persist CRUD changes with explicit transactions

In this lesson you will persist CRUD changes with explicit transactions. Work with the Equipment Rental API in the downloadable lab. The reference is a complete solution with separate lesson checks, so you can inspect the answer, make a deliberate local change and verify its behavior.

A transaction makes a set of writes succeed together or leave no partial result. create_equipment begins one transaction, adds the item, flushes so database errors and generated values are available, constructs the response, and exits the context to commit. The caller receives the response only after commit finishes. flush sends SQL but does not make the change durable by itself.

Rollback matters when a later operation fails. The lesson changes an existing item and attempts a duplicate name in the same transaction. PostgreSQL rejects the duplicate; the earlier name change must also disappear. Separate commits would preserve that partial update and violate the request's promise. PATCH uses exclude_unset so untouched fields stay unchanged, and explicit null is rejected where the schema cannot accept it. A transaction context owns commit and rollback; lower-level helper functions should not introduce surprise commits. When catching a database error, finish or roll back the failed transaction before using the session again. Return a stable conflict, rather than pretending that a partially applied operation succeeded.

The integrated routes also read equipment and delete only equipment with no rental history. Deletion locks the parent and rejects any referenced item with 409; it never erases a rental to make deletion succeed. The final endpoint integration check exercises create, read, update and this safe deletion rule.

Worked source: equipment/services.py, create_equipment.

Read create_equipment and patch_equipment in services.py. The lesson08 check reads a created item through a new session, forces a later uniqueness failure, and confirms the earlier change rolled back. It also rejects explicit null. Notice which assertions would still pass after flush alone and which require committed visibility.

def create_equipment(session, data):
    with session.begin():
        item = Equipment(**data.model_dump())
        session.add(item)
        session.flush()
        result = EquipmentOut.model_validate(item)
    return result  # commit completed before the caller can send success

python run_checks.py -k lesson08