Jak działają migracje?

Question

Accepted Answer

**Migracje** to sposób Django na propagowanie zmian, które wprowadzasz w modelach (dodanie pola, utworzenie modelu), do **schematu bazy danych** — są to kontrolowane wersjami, automatycznie generowane pliki zmian bazy danych. Zmieniasz modele w Python; migracje utrzymują bazę danych w synchronizacji. ## Dwuetapowy przepływ pracy ```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` wykrywa zmiany modelu i generuje plik migracji; `migrate` stosuje oczekujące migracje do rzeczywistej bazy danych. Piszesz Python (zmiany modelu), a Django generuje i uruchamia SQL. ## Plik migracji to kod kontrolowany wersjami ```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), ), ] ``` Migracje są **zatwierdzane do kontroli wersji**, więc historia schematu bazy danych jest śledzona razem z kodem. Każdy deweloper i każde środowisko stosuje te same migracje, aby osiągnąć ten sam schemat — powtarzalne i spójne. ## Dlaczego to ważne (vs ręczny 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 ``` ## Przydatne komendy i koncepcje ```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 ``` ## Migracje danych (nie tylko schematu) ```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. ``` ## Dlaczego to ważne Migracje są niezbędne do pracy z warstwą bazy danych Django — rozwiązują krytyczny problem utrzymania synchronizacji schematu bazy danych z modelami Python w bezpieczny, powtarzalny, przyjazny dla zespołu sposób. Rozumienie ich to fundamentalna, codzienna wiedza: przepływ pracy `makemigrations` → `migrate` to sposób, w jaki każda zmiana schematu się odbywa (zmieniasz modele, Django generuje i stosuje SQL), więc nie możesz rozwijać aplikacji Django opartej na danych bez tego. Kluczowa wartość polega na tym, że migracje sprawiają, że zmiany schematu są **kontrolowane wersjami** (śledzone razem z kodem, możliwe do przejrzenia w pull requestach), **powtarzalne** (każde środowisko — maszyna każdego dewelopera, staging, produkcja — osiąga identyczny schemat, uruchamiając te same migracje), i **bezpieczne** (Django generuje poprawny, często odwracalny SQL zamiast podatnych na błędy ręcznych instrukcji `ALTER TABLE`). To eliminuje całą kategorię problemów związanych z drytem schematu, niespójnymi środowiskami i ryzykownymi ręcznymi zmianami bazy danych. Wiedza o przepływie pracy, że migracje są zatwierdzane do kontroli źródła, jak je inspektować i wycofywać, oraz że mogą również obsługiwać **transformacje danych** (backfilling/migrację danych, nie tylko schematu) jest konieczna dla każdego rzeczywistego projektu Django. Migracje to sposób, w jaki zespoły Django rozwijają schemat bazy danych współpracując i niezawodnie przez cały okres trwania projektu, czyniąc ten materiai podstawowym, którym trzeba się zaznajomić.