Commit a Completed Checkout

Begin with the outcome where both proposed loans are valid. The durable success point belongs after both inserts, because reaching it means the complete pair succeeded.

Your project already contains schema.sql. It recreates the three familiar tables and should stay unchanged. Work in transactions.py. When you press Run, the visible run_transactions.py file creates fresh databases, calls your functions with the displayed arguments, and reports what another connection can read. Leave that runner unchanged.

Open transactions.py. checkout_pair(connection, first_loan, second_loan) already executes the same parameterized INSERT twice. Each proposed loan has this exact shape:

(id, item_id, member_id, checked_out_on)

Add one line after both execute() calls and before return True:

connection.commit()

commit() makes the successful changes durable. A fresh connection can then read them. Placing it after the first insert would split the operation again: if the second insert failed, the first would already be durable.

Press Run. The first fixed case calls:

checkout_pair(
    connection,
    (7001, 4, 17, "2026-08-26"),
    (7002, 5, 28, "2026-08-26"),
)

It should return True, and reopening should show [7001, 7002].

The same Run also shows a missing-member pair. For now, it stops with a database-rule error. The acting connection can see the first proposed row, while a reopened connection sees neither because the success point was never reached. Keep that unresolved state in mind; it shows exactly what the failure path still needs to fix.

Submit calls checkout_pair with different values. It checks the exact stored values through a separate connection and then runs a harmless query through the supplied connection. Do not close the connection inside the function; the caller owns its lifetime.