makemigrations versus migrate

migrate neemt die migratiebestanden en voert ze daadwerkelijk uit op de database, waarbij echte tabellen worden gemaakt of aangepast.

Door plan en uitvoering te scheiden kun je een wijziging beoordelen, deze naar git committen en exact dezelfde stappen op elke machine en server uitvoeren.

Elk plan staat als bestand in je app onder migrations/. Je commit deze bestanden, zodat teamgenoten identieke wijzigingen kunnen toepassen.

Bewerk een model, voer makemigrations uit om de wijziging vast te leggen en voer daarna migrate uit om deze toe te passen. Die lus is je dagelijkse schemaworkflow.

Voeg een duidelijk label toe, zodat bestanden op een geschiedenis lijken en niet op een stapel getallen. Gebruik de vlag --name om te beschrijven wat er is veranderd.

Geef een applabel door om migraties alleen voor die app te genereren of toe te passen, zodat niet-gerelateerde wijzigingen buiten beeld blijven.

Voer in CI makemigrations uit met --check om de build te laten mislukken als een modelwijziging nog geen bijbehorende migratie heeft.

Het commando showmigrations geeft elke migratie weer en markeert de toegepaste migraties met een X, zodat je precies weet wat de huidige toestand is.

Voer altijd eerst makemigrations uit en daarna migrate. Als je alleen migrate uitvoert, worden alle bestaande plannen toegepast, ook de ingebouwde plannen van Django.

Je hebt het ritme geleerd: makemigrations schrijft het plan en migrate past het toe. Eerst plannen, daarna toepassen, zodat je schema overal synchroon blijft. 🎉