Ответ
Django отслеживает примененные миграции с помощью специальной таблицы в базе данных под названием django_migrations.
Ключевые моменты:
-
Таблица
django_migrationsЭта таблица создается автоматически при первом запуске командыpython manage.py migrate. Она содержит запись для каждой успешно примененной миграции.Ее структура проста:
id: Первичный ключ.app: Название приложения, к которому относится миграция.name: Имя файла миграции (например,0001_initial).applied: Дата и время применения миграции.
-
Процесс работы команды
migrateКогда вы запускаетеpython manage.py migrate, Django выполняет следующие шаги:- Сканирует директории
migrations/всех приложений проекта и находит все файлы миграций. - Сравнивает найденный список миграций со списком миграций, записанных в таблице
django_migrations. - Определяет, какие миграции еще не были применены.
- Выполняет SQL-команды для каждой непримененной миграции в правильном порядке (учитывая зависимости).
- После успешного выполнения каждой миграции добавляет новую запись в таблицу
django_migrations.
- Сканирует директории
Практическая проверка статуса
Самый простой способ проверить, какие миграции применены, а какие нет — использовать команду showmigrations:
# Показать статус миграций для всех приложений
python manage.py showmigrations
# Показать статус для конкретного приложения
python manage.py showmigrations my_appВывод команды помечает примененные миграции символом [X]:
my_app
[X] 0001_initial
[X] 0002_add_price_field
[ ] 0003_add_tagsТаким образом, таблица django_migrations является единственным источником правды о состоянии схемы базы данных с точки зрения Django.
Ответ 18+ 🔞
А, слушай, ну это же классика, блядь! Джага, как старый пердун, не доверяет никому, даже своей тени. Он же не будет каждый раз, как ты команду migrate запускаешь, в БД лезть и глазами сравнивать, что там нахуй натворили. У него своя, хитрая жопа, система учёта!
Вот как это работает, ёпта:
-
Волшебная табличка
django_migrationsЭта штука — его личный блокнотик, куда он записывает все свои грехи. Создаётся она автоматом, как только ты впервые накосячил и сказалpython manage.py migrate. Сидит себе в базе и тихо посмеивается.Устроена проще пареной репы, смотри:
id: Ну, чтоб отличать одну запись от другой, а то совсем дебилы что ли.app: Какой приложухой накосячили.name: Конкретно какой файлик с миграцией (ну, типа0001_initial,0002_add_price_field— понятно же).applied: Когда именно этот пиздец произошёл, дата и время.
-
Что происходит, когда ты говоришь
migrateДжага, сука, включает режим параноика и делает вот что:- Лезит во все папки
migrations/и выписывает на листочек ВСЕ найденные файлы. Все до одного, блядь. - Достаёт свой блокнотик (
django_migrations) и сверяет список с тем, что в базе. "Так-так,0001_initial— галочка есть,0002_add_price_field— тоже... А0003_add_tags— о, сука, нет галочки! Значит, не применяли ещё, пизда!" - Берёт все неприменённые миграции, расставляет их по порядку (чтобы зависимости не поехали, а то будет овердохуища проблем) и начинает в БД впендюривать SQL-команды из них.
- Как только миграция прошла успешно — БАЦ! — сразу же ставит галочку в свой блокнотик, новую запись в
django_migrations. Всё, точка, забыли. Больше эту миграцию трогать не будет, пока не скажешь откатить.
- Лезит во все папки
Как на практике посмотреть, где мы накосячили?
Да проще пареной репы, блядь! Есть команда showmigrations — она как раз и показывает этот самый блокнотик в удобном виде.
# Показать всё, что натворили во всех приложухах
python manage.py showmigrations
# Или только по одной конкретной, если подозрение ебать чувствую
python manage.py showmigrations my_appВыдаст тебе что-то вроде:
my_app
[X] 0001_initial
[X] 0002_add_price_field
[ ] 0003_add_tagsВидишь? [X] — значит, уже впендюрили в базу и записали в блокнотик. [ ] — значит, файл есть, а в базе хуй с горы, не применяли. Вот и вся магия, блядь. Эта таблица django_migrations — и есть единственный источник правды, по которому Джага понимает, в каком состоянии его база данных. Без неё он бы просто охуел и сломался.