Waarom u migraties nodig hebt in plaats van create_all

Echte apps evolueren, dus je tabellen moeten dat ook doen. Je voegt kolommen toe, hernoemt velden en verwijdert oude velden wanneer functies groeien. 🔄

Onthoud de beperking die je eerder zag: create_all maakt alleen ontbrekende tabellen. Een bestaande tabel wordt nooit aangepast.

Een verleidelijke oplossing is de tabel verwijderen en opnieuw maken. Dat werkt in een demo, maar het verwijdert elke rij, wat in productie ondenkbaar is.

Ruwe ALTER TABLE-opdrachten met de hand uitvoeren op een live database is kwetsbaar. Eén typefout of overgeslagen stap kan gegevens beschadigen, zonder eenvoudige manier om dit ongedaan te maken.

Een migratie is een klein script dat je schema in veilige, herhaalbare stappen van de ene versie naar de volgende brengt.

Elke migratie heeft een versie-id en verwijst naar de vorige. Samen vormen ze een geordende geschiedenis van elke schemawijziging.

Een migratie definieert twee paden: upgrade voert de wijziging uit en downgrade draait die terug als er iets misgaat.

Flask-Migrate koppelt je app aan Alembic, het hulpmiddel dat schemawijzigingen detecteert en de migratiescripts voor je schrijft.

Migraties slaan de huidige schemaversie op in een tabel met de naam alembic_version, zodat het hulpmiddel altijd weet waar je bent.

Dezelfde migratiescripts draaien op je laptop, in CI en in productie, zodat elke omgeving uiteindelijk een identiek schema heeft.

Gebruik create_all alleen voor het allereerste prototype. Zodra je model begint te veranderen, stap je definitief over op migraties.

Je hebt gezien waarom create_all een schema niet kan uitbreiden en hoe migraties veilige, geversioneerde en omkeerbare wijzigingen mogelijk maken. 🎉