Перейти на PRO

Что такое миграции в Django и как они работают

Тип вопроса: Django Вероятность: 22% Категория: Python Разработчик

Ответ

Миграции в Django — это система контроля версий для схемы вашей базы данных. Они позволяют эволюционно изменять модели и автоматически применять эти изменения к БД, сохраняя при этом данные.

Основной принцип работы:

  1. Изменение моделей: Вы вносите изменения в файл models.py (например, добавляете новое поле).
  2. Создание миграции: Команда python manage.py makemigrations анализирует изменения и генерирует файл миграции — Python-код, описывающий, как перейти от старого состояния схемы к новому.
  3. Применение миграции: Команда python manage.py migrate выполняет код из файла миграции, изменяя структуру таблиц в базе данных.

Django отслеживает примененные миграции в специальной таблице django_migrations.

Пример:

Допустим, у нас есть модель Project:

# myapp/models.py
from django.db import models

class Project(models.Model):
    name = models.CharField(max_length=200)

Теперь добавим поле deadline:

# myapp/models.py
from django.db import models

class Project(models.Model):
    name = models.CharField(max_length=200)
    deadline = models.DateField(null=True, blank=True) # Новое поле

Выполняем команды в терминале:

# 1. Создаем файл миграции (например, 0002_project_deadline.py)
python manage.py makemigrations myapp

# 2. Применяем миграцию к базе данных
python manage.py migrate myapp

Ключевые преимущества:

  • Надежность: Изменения схемы версионируются и применяются последовательно.
  • Командная работа: Все разработчики работают с единой историей изменений схемы БД.
  • Автоматизация: Не нужно писать SQL-запросы вручную для изменения таблиц.

Ответ 18+ 🔞

О, смотри-ка, миграции в Django, ну это же просто пиздец как важно, ага. Представь себе, ты пишешь модель, всё работает, а потом бац — надо добавить поле. И что, вручную лезть в базу и SQL-скрипты городить? Да ну нахуй, это же каменный век, блядь.

Вот как это работает, по-человечьи:

  1. Ты накосячил в моделях. Ну или не накосячил, а просто добавил что-то. Допустим, была модель Project с одним полем name. А ты решил, что мало, и впихнул туда ещё deadline. В рот меня чих-пых, теперь надо базу под это дело перелопатить.
  2. Ты говоришь Джанге: «Слушай, я тут натворил, сделай что-нибудь». 
    python manage.py makemigrations myapp

    Джанга смотрит на твой models.py, потом на то, что уже в базе, и охуевает от разницы. Но не паникует, а пишет на Питоне инструкцию «как из состояния А попасть в состояние Б». Это и есть файл миграции — типа 0002_project_deadline.py. Там по полочкам разложено: «создать колонку deadline в таблице myapp_project, да ещё и null=True сделать, чтоб старые записи не посыпались».

  3. Ты говоришь Джанге: «Ну так примени уже эту хуйню». 
    python manage.py migrate myapp

    И она берёт эту инструкцию и аккуратно, блядь, выполняет её на реальной базе. Всё, поле добавилось. А чтобы не запутаться, что уже сделано, а что нет, она ведёт учёт в специальной таблице django_migrations. Типа журнал учёта, чтобы не наебнуться и не применить одно и то же дважды.

А зачем это всё, спросишь? Да затем, сука, что без этого — пиздец и бардак.

  • Не надо быть гуру SQL. Не нужно самому писать ALTER TABLE myapp_project ADD COLUMN deadline date NULL;. Джанга за тебя всё сделает, и сделает правильно, ёпта.
  • Всё под контролем. Каждое изменение — это файл. Его можно в гите закоммитить, посмотреть историю, откатиться если чё. Красота, блядь.
  • В команде не перебьёшь друг другу руки. Один сделал миграцию, залил в репу, другой потянул и применил. И никто никого не послал нахуй из-за конфликта схемы.

Вот смотри, как это выглядит вживую. Было:

# myapp/models.py
from django.db import models

class Project(models.Model):
    name = models.CharField(max_length=200)

Стало:

# myapp/models.py
from django.db import models

class Project(models.Model):
    name = models.CharField(max_length=200)
    deadline = models.DateField(null=True, blank=True) # Новое поле, ёбана!

И в терминале:

# 1. Джанга, сообрази на бумажке, что делать!
python manage.py makemigrations myapp

# 2. А теперь иди и сделай это!
python manage.py migrate myapp

Всё, готово. Никакого ручного геморроя. Главное — не забывай делать makemigrations после изменений в моделях, а то потом будешь охуевать, почему код есть, а поля в базе нет. И да, migrate применяй, а то файлы миграций будут как мёртвому припарки — лежать и пылиться.

© ХакСобесов, 2026
support@hacksobesov.com