Что такое фейковые миграции в Django и в каких случаях их применяют

Question

Что такое фейковые миграции в Django и в каких случаях их применяют

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

Ответ

Фейковые (fake) миграции в Django — это процесс пометки миграций как выполненных в базе данных без фактического выполнения соответствующих SQL-запросов для изменения схемы.

Это мощный, но рискованный инструмент, который используется в строго определенных ситуациях.

Основные сценарии использования:

Синхронизация состояния. Когда схема базы данных уже находится в нужном состоянии (например, изменения были применены вручную или другим инструментом), но Django об этом не знает.
Разрешение конфликтов миграций. При слиянии веток, когда история миграций расходится, но итоговая схема БД корректна.
Начальная настройка проекта. При развертывании существующего проекта на новую базу данных, которая уже создана с нужной схемой (например, через sqlmigrate).

Как применить:

Чтобы пометить все еще не примененные миграции в приложении как выполненные:

python manage.py migrate --fake my_app

Чтобы пометить конкретную миграцию:

python manage.py migrate --fake my_app 0002_some_migration_name

Важные предостережения:

Используйте с осторожностью. Неправильное применение может привести к рассинхронизации состояния схемы БД и моделей Django, что вызовет трудноуловимые ошибки.
Убедитесь в соответствии схемы. Перед выполнением --fake вы должны быть на 100% уверены, что структура таблиц в БД соответствует тому, что ожидает миграция.
Не применяйте к initial миграциям на уже существующей базе с данными, если вы не уверены в полном совпадении схем.

Ответ 18+ 🔞

Ну вот, сидишь ты такой, ковыряешься в своём проекте, а тут — бац! — миграции, сука, поехали. История веток переплелась, как корни у ёбушкиного дерева, и Django смотрит на базу с таким подозрением, будто видит пизда с ушами. А база-то уже в нужном состоянии! Всё руками накатил, или скриптами, или ещё какой хуйнёй. И тут на помощь приходит наш старый друг — фейковая миграция. Это когда ты говоришь Джанге: «Слушай, чувак, всё уже сделано, просто отметь галочку, что ты это видел, и иди нахуй».

Когда это, блядь, нужно?

Синхронизация ебалы и реальности. База уже выглядит так, как задумано. Таблицы есть, поля на месте, индексы торчат. А Джанга орёт: «А ну-ка примени миграцию 0042!». А её применять уже некуда, всё стоит. Вот тут и делаешь --fake. Типа «да-да, я уже всё сделал, вот тебе печенька, отстань».
Конфликты, блядь, при слиянии. Работали в двух ветках, наделали миграций, потом слили. История разъехалась, как говно по асфальту. Но если приглядеться, итоговая схема в БД — одна и та же. Вместо того чтобы разгребать этот пиздец вручную, можно аккуратно нафейкать нужные миграции, чтобы django_migrations успокоилась.
Разворачиваешь проект на новом месте. Допустим, есть у тебя продовая база, или дамп, или схема, созданная не миграциями Джанги. Поднимаешь новый инстанс, а запускать 150 миграций с нуля — это овердохуища времени. Сделал sqlmigrate, накатил одним скриптом, а потом фейком пометил все миграции как выполненные. Красота, блядь.

Как, сука, это делается?

Хочешь пометить всё невыполненное дерьмо в приложении my_app? Пожалуйста:

python manage.py migrate --fake my_app

А если нужно конкретно одну, вот эту, с номером 0002 и хитрожопым именем?

python manage.py migrate --fake my_app 0002_some_migration_name

А теперь, блядь, слушай сюда, главное!

Это не игрушка, это острый нож. Терпения ноль ебать, нужно быть внимательным.

Совпадение должно быть стопроцентным. Перед тем как нажать Enter, ты должен быть уверен, как в том, что Земля круглая, что структура твоей базы идеально совпадает с тем, что хотела бы сделать эта миграция. Не «вроде», не «почти», а идеально. Иначе потом будешь ловить ошибки, от которых волосы завьются.
С initial — отдельная песня. Фейкануть начальную миграцию на базе, где уже есть живые данные, — это как играть в русскую рулетку с полным барабаном. Если не уверен на все 150% — не делай. Сначала разберись, что у тебя в БД валяется.
Последствия. Если накосячишь, Джанга начнёт генерировать SQL, который будет пытаться создать уже существующие таблицы или удалить несуществующие поля. Короче, пиздец.

В общем, инструмент мощный, но, как говорится, доверия ебать ноль. Проверяй всё дважды, прежде чем фейкать. А то мало не покажется.