Hur fungerar migrations?

Question

Accepted Answer

**Migrations** är Django:s sätt att sprida ändringar du gör i dina modeller (lägga till ett fält, skapa en modell) till **databasschemat** — de är versionskontrollerade, automatiskt genererade databassändringsfiler. Du ändrar modeller i Python; migrations håller databasen i synk. ## Arbetsflödet i två steg ```bash # 1. you change a model in models.py (e.g. add a field)... # 2. generate a migration file describing the change python manage.py makemigrations # → creates migrations/0002_article_views.py (the change, as Python) # 3. apply the migration to the database python manage.py migrate # → runs the SQL to alter the database schema (ADD COLUMN, etc.) ``` `makemigrations` detekterar modelländringar och genererar en migrationsfil; `migrate` tillämpar väntande migrationer på den faktiska databasen. Du skriver Python (modelländringar), och Django genererar och kör SQL:en. ## En migrationsfil är versionskontrollerad kod ```python # migrations/0002_article_views.py (auto-generated) class Migration(migrations.Migration): dependencies = [("blog", "0001_initial")] # ordering — depends on the previous one operations = [ migrations.AddField( # the change model_name="article", name="views", field=models.IntegerField(default=0), ), ] ``` Migrationer är **committade till versionskontroll**, så databasschemats historik spåras tillsammans med koden. Varje utvecklare och miljö tillämpar samma migrationer för att nå samma schema — reproducerbar och konsistent. ## Varför migrations spelar roll (jämfört med manuell SQL) ```text ✓ Schema changes are version-controlled (tracked with the code, reviewable in PRs) ✓ Reproducible — every dev/staging/production DB gets the same schema by running migrate ✓ No manual, error-prone SQL — Django generates the correct ALTER statements ✓ Reversible — many migrations can be rolled back (migrate ) ✓ Team-friendly — schema changes flow through the normal code-review process ``` ## Användbara kommandon och koncept ```bash python manage.py showmigrations # see which migrations are applied/pending python manage.py sqlmigrate blog 0002 # preview the SQL a migration will run python manage.py makemigrations --empty # a blank migration for custom/data changes python manage.py migrate blog 0001 # roll BACK to a previous migration ``` ## Datamigrations (inte bara schema) ```text Migrations can also transform DATA (e.g. populate a new field, backfill values) via RunPython operations — useful when a schema change needs accompanying data changes. ``` ## Varför det spelar roll Migrationer är väsentliga för att arbeta med Django:s databaslager — de löser det kritiska problemet med att hålla databasschemat i synk med dina Python-modeller på ett säkert, reproducerbart, teamvänligt sätt. Att förstå dem är grundläggande vardagskunskap: `makemigrations` → `migrate`-arbetsflödet är hur varje schemaändring sker (du ändrar modeller, Django genererar och tillämpar SQL:en), så du kan inte utveckla en datadrivet Django-app utan det. Huvudvärdet är att migrationer gör schemaändringar **versionskontrollerade** (spårade tillsammans med kod, granskas i pull requests), **reproducerbara** (varje miljö — varje utvecklares dator, staging, produktion — når det identiska schemat genom att köra samma migrationer), och **säkra** (Django genererar korrekt, ofta reversibel SQL istället för felbenägna manuella `ALTER TABLE`-satser). Detta eliminerar en helt kategori av problem omkring schemadrift, inkonsekventa miljöer och riskfyllda manuella databassändringar. Att känna till arbetsflödet, att migrationer är committade till källkodskontroll, hur man inspekterar och återställer dem, och att de också kan hantera **datatransformationer** (förifyllning/migrering av data, inte bara schema) är nödvändigt för alla verkliga Django-projekt. Migrationer är hur Django-team utvecklar sitt databasschema tillsammans och tillförlitligt under ett projekts livstid, vilket gör detta till centralt, måste-veta-material.