Create, Import, and Evolve a Schema · practice
Move Version 1 Forward
A catalog can outlive the first version of its schema. Suppose catalog.db already contains member 17 as Riley Chen, and its stored version is 1. Rebuilding all three tables would put that real row at risk. Your job in catalog_setup.py is smaller: change that exact old shape in place.
Run calls migrate_v1_to_v2(connection) with an open connection to a temporary version 1 database. The supplied setup has these member columns before your call:
id, member_code, name, loan_limit
After a successful call, Run closes and reopens the file. It should show:
== move version 1 forward ==
Before: version 1; member columns id, member_code, name, loan_limit
Call: migrate_v1_to_v2(connection)
After: version 2; member columns id, member_code, name, loan_limit, email
M-17: Riley Chen | email NULL
Use the three SQL migrate_v1_to_v2: start a email TEXT to members, then record version 2. Call commit() once, after both changes succeed. If either change fails, call rollback() and let the original
SQLite fills the new nullable column with NULL for existing rows. That is why Riley’s name and all other stored values survive while the new email is initially absent. This is a forward migration: it knows one old shape and moves it to one current shape. It does not try to guess how to repair arbitrary databases.
The explicit BEGIN matters here for the same reason it mattered during initialization. The DDL sequence must already be inside one transaction before the first schema change runs. A connection context by itself does not start this particular DDL sequence soon enough.
Leave the supplied connection open. Its caller chose the path and owns its lifetime; this
Run uses a temporary file, so each click begins again from the same safe version 1 row.
Task
Complete migrate_v1_to_v2(connection) in catalog_setup.py.
Execute BEGIN, add nullable members.email, set PRAGMA user_version = 2, and commit once. On any