Maak een schema, importeer gegevens en ontwikkel het verder · oefening
Werk versie 1 bij naar de volgende versie
Een catalogus kan langer meegaan dan de eerste versie van zijn schema. Stel dat catalog.db lid 17 al bevat als Riley Chen, en dat de opgeslagen versie 1 is. Alle drie de tabellen opnieuw opbouwen zou die echte rij in gevaar brengen. Je taak in catalog_setup.py is kleiner: verander die exacte oude structuur ter plekke.
Run roept migrate_v1_to_v2(connection) aan met een open verbinding naar een tijdelijke database van versie 1. De meegeleverde beginsituatie heeft vóór je aanroep deze ledenkolommen:
id, member_code, name, loan_limit
Na een geslaagde aanroep sluit Run het bestand en opent het opnieuw. Het moet dit tonen:
== 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
Gebruik de drie SQL-strings die al in migrate_v1_to_v2 staan: begin een transactie, voeg email TEXT toe aan members en leg daarna versie 2 vast. Roep commit() één keer aan, nadat beide wijzigingen zijn geslaagd. Als een van de wijzigingen mislukt, roep je rollback() aan en laat je de oorspronkelijke exception doorgaan.
SQLite vult de nieuwe kolom, die ontbrekende waarden toestaat, voor bestaande rijen met NULL. Daardoor blijven Riley’s naam en alle andere opgeslagen waarden behouden, terwijl het nieuwe e-mailadres aanvankelijk ontbreekt. Dit is een voorwaartse migratie: die kent één oude structuur en zet die om naar één huidige structuur. Ze probeert niet te raden hoe willekeurige databases moeten worden hersteld.
Het expliciete BEGIN is hier om dezelfde reden van belang als tijdens de initialisatie. De DDL-reeks moet al binnen één transactie staan voordat de eerste schemawijziging wordt uitgevoerd. Een verbindingscontext op zichzelf begint deze specifieke DDL-reeks niet vroeg genoeg.
Laat de meegegeven verbinding open. De aanroeper heeft het pad gekozen en beheert de levenscyclus; deze functie beheert alleen de migratietransactie.
Run gebruikt een tijdelijk bestand, dus begint elke klik opnieuw met dezelfde veilige rij van versie 1.
Opdracht
Maak migrate_v1_to_v2(connection) in catalog_setup.py af.
Voer BEGIN uit, voeg members.email toe met ruimte voor een ontbrekende waarde, stel PRAGMA user_version = 2 in en commit één keer. Draai bij elke exception de transactie terug en werp dezelfde exception opnieuw op. Behoud alle bestaande rijen en laat de meegegeven verbinding open.