Ответ
Управление миграциями в Django осуществляется через утилиту manage.py. Основной цикл работы включает создание файлов миграций на основе изменений в моделях и их последующее применение к базе данных.
1. Создание и применение миграций
Двухэтапный процесс для обновления схемы БД:
- Создать файл миграции:
Команда анализирует изменения в файлах
models.pyи создает новый файл миграции в папкеmigrationsсоответствующего приложения.python manage.py makemigrations <app_name> - Применить миграции к БД:
Команда выполняет все еще не примененные миграции, изменяя схему базы данных в соответствии с ними.
python manage.py migrate
2. Откат миграций
Откат позволяет вернуть схему базы данных к состоянию определенной миграции.
- Откат до конкретной миграции:
Укажите имя приложения и имя файла миграции, к состоянию до которой нужно вернуться.
# Пример: откат миграции 0003_... в приложении 'myapp' # Нужно указать предыдущую миграцию - 0002 python manage.py migrate myapp 0002_some_previous_migration - Полный откат всех миграций приложения:
Используется специальное имя миграции
zero.python manage.py migrate myapp zero
3. Полезные команды
- Показать статус миграций:
Отображает список всех миграций и помечает примененные (
[X]).python manage.py showmigrations - Показать SQL-код миграции:
Генерирует SQL-запросы, которые будут выполнены для указанной миграции, без их реального применения.
python manage.py sqlmigrate myapp 0003_some_new_migration
Ответ 18+ 🔞
Давай разберём эту скучную документацию про миграции в Django, как будто я тебе объясняю за кружкой пива, а не на корпоративном тренинге. Сиди, слушай, не перебивай.
Вот смотри, вся эта движуха с миграциями — это как история с Герасимом и Муму, только про базу данных. Ты меняешь модель в models.py — это как Герасим решил, что собаке нужно не будку, а трёхкомнатную квартиру. Но база данных-то об этом не знает, она как барыня-помещица: «А я не разрешала!». Чтобы база не охуела от твоих самодеятельных изменений, нужен официальный приказ — файл миграции.
1. Рождение и внедрение миграции (Двухэтапный пиздец)
Сначала ты пишешь в models.py, что хочешь добавить поле is_awesome = models.BooleanField(default=True). База данных в этот момент смотрит на тебя как на идиота и говорит: «А у меня, сука, такого поля нет!».
Этап первый: Создание бумажки (makemigrations). Ты командуешь Джанго: «Слушай, братва, я тут накосячил в коде, сделай мне официальную бумажку, чтобы база не взбрыкнула».
python manage.py makemigrations myappДжанго идёт, смотрит на твои модели, хмыкает и создаёт в папке migrations файлик типа 0004_add_field_is_awesome.py. Это и есть та самая бумага с печатью, приказ для базы. Пока что это просто текст, ничего не произошло. База всё ещё охуевает.
Этап второй: Исполнение приказа (migrate). Теперь ты эту бумажку суёшь базе данных под нос:
python manage.py migrateБаза читает, вздыхает, говорит «Ну блядь, опять эти программисты со своими приколами...» — и на самом деле создаёт в таблице новый столбец. Вот теперь всё, схема обновлена. Герасим (твой код) может спокойно обращаться к полю is_awesome, а база (барыня) уже не возмущается.
2. Откат, или «Ой, бля, я накосячил!»
Бывает такое — добавил поле, запустил миграцию, а потом понял, что это была пиздец какая-то идея. Надо всё откатить. Это как если бы Герасим, утопив Муму, вдруг осознал: «Что же я, мудак, сделал?».
-
Откат до конкретной точки: Допустим, у тебя есть миграции 0001, 0002, 0003. Ты применил 0003, а она оказалась говном. Надо откатиться к состоянию после 0002.
python manage.py migrate myapp 0002_previous_migration_nameДжанго возьмёт и отменит все операции из миграции 0003. База вернётся в то состояние, в котором была после 0002. Всё, как будто 0003 и не было. Чисто, аккуратно.
-
Полный пиздец и обнуление (migrate zero): Это когда ты так заигрался, что проще всё начать с чистого листа для этого приложения.
python manage.py migrate myapp zeroЭта команда — аналог «Иди нахуй, мужик!». Она откатывает ВСЕ миграции приложения
myapp. Все таблицы, которые были созданы миграциями этого приложения, будут накрыты медным тазом (удалены). Используй с умом, а то так и до «вротберунчика» недалеко.
3. Полезные фишки, чтобы не облажаться
-
showmigrations— «А что у нас по статусу?» Запустишь — и тебе выведется список всех миграций всех приложений. Те, что уже применены, будут с галочкой[X]. Те, что нет — с пробелом[ ]. Сразу видно, кто в лес, кто по дрова. Охуенно полезно, когда непонятно, что уже накатилось, а что нет.python manage.py showmigrations -
sqlmigrate— «А что ты, сука, собираешься сделать?» Самая хитрая команда. Она не применяет миграцию, а показывает SQL-код, который будет выполнен. Это как заглянуть в будущее. Хочешь проверить, не снесёт ли миграция0003твою любимую таблицуusers? Посмотри SQL!python manage.py sqlmigrate myapp 0003_add_field_is_awesomeВыведет что-то вроде
ALTER TABLE "myapp_mymodel" ADD COLUMN "is_awesome" boolean DEFAULT TRUE NOT NULL;. Теперь ты точно знаешь, что тебя ждёт. Волнение ебать — ноль.
Короче, суть: makemigrations — это написать приказ, migrate — это его исполнить. А всякие showmigrations и sqlmigrate — это чтобы не быть слепым пиздюком и понимать, что происходит. Всё просто, как три копейки. Главное — не путать этапы, а то получится как у того немого Герасима: хотел как лучше, а в итоге — «Мууу...».