Команды manage.py для взаимодействия с базой данных в Django

В данной статье описываются основные команды модуля manage.py для работы с изменениями структуры базы данных в Django

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

Команда makemigrations

С помощью этой команды можно создавать и формализовывать изменения, которые необходимо внести в текущую схему базы данных, на основании изменений, внесенных в модель. Общий синтаксис команды следующий:

python manage.py makemigrations [app_label [app_label ...]]

После запуска этой команды для перечисленных приложений (а если они не указаны, то для всех приложений проекта), Django начнет сканировать и сравнивать модели приложений с версиями, которые содержаться в текущий момент в миграционных файлах проекта и затем новый набор изменений будет записан в новый файл миграций. Необходимо проверять сформированные миграции, чтобы понять какие параметры схемы утилита makemigrations посчитала измененными. Она не идеальна и для сложных изменений она может определить совсем не те изменения, которые вы ожидаете.

В результате работы данной утилиты формируется файл миграции, который является подклассом для migrations.Migration. Давайте рассмотрим один в качестве примера:

from django.db import migrations, models

class Migration(migrations.Migration):
     dependencies = [('migrations', '0001_initial')]
     operations = [
          migrations.DeleteModel('Tribble'),
          migrations.AddField('Author', 'rating', models.IntegerField(default=0)),
     ]

Основными атрибутами класса, с которым обычно сталкивается Django в процессе миграций, являются:

Зависимости (dependencies) - список миграций, которые являются предшественниками для данного изменения и с которыми осуществялось сравнение текущих атрибутов модели. operations - список операций, которые необходимо совершить над схемой базы данных в рамках данной миграции.
Операции (operations) - представляют собой определенным образом объявленные инструкции, которые говорят Django какие изменения схемы должны быть произведены. Django сканирует их и готовит представление всех изменений схемы базы данных, которое затем использует для генерации SQL команд необходимых для изменения схемы базы данных.

Вам редко, если вообще когда-либо потребуется редактировать файлы миграции вручную, но это вполне возможно сделать, если вам это нужно. Некоторые из большинства сложных операций Django не удастся идентифицировать автоматически и единственным возможным способом их применить будет написание миграции вручную.

Некоторые дополнительные полезные ключи, которые можно применять вместе с утилитой makemigrations:

--empty

Формирует пустой файл миграции для конкретного приложения для ручного редактирования. Только для продвинутых пользователей.

--merge

Позволяет анализировать и фиксить возможные конфликты при миграции.

--dry-run

Запускает процесс анализа и создания файла миграции, но при этом сам файл не записывает. Можно использовать для проверки наличия изменений в модели и анализа изменений, которые будут отражены в файле миграций.

--no-header

Генерирует файл миграции, в заголовке которого отсутствует версия Django и отметка о дате и времени создания.

--name

Если вы хотите сами задать имя файлу миграции, вместо автоматически генерируемого, то нужно использовать опцию --name в следующем формате:

python manage.py makemigrations --name changed_my_model your_app_label

Команда migrate

Как только у нас появился новый файл миграции, либо автоматически с использованием утилиты makemigrations, либо созданный руками, изменения, которые хранятся в нем нужно применить с существующей схеме базы данных. Для этого используется команда migrate.

Общий синтаксис применения команды, согласно официальной документации, следующий:

django-admin migrate [app_label] [migration_name]

Результаты выполнения этой команды зависят от передаваемых аргументов:

без аргументов: к текущей схеме базы данных будут применены все миграции для всех приложений.
имя приложения <app_label>: миграции будут запущены только для указанного приложения, до самой последней миграции включительно. Это также может включать в себя запуск миграций и у других приложений, если существуют зависимости между ними.
имя приложения и имя миграции <app_label> <migrationname>: Переводит схему базы данных в состояние той миграции, которая указана в команде. Миграции после указанной не применяются. Это может повлечь за собой наличие не примененных миграций, если перед этим уже были применены более поздние миграции. Можно использовать префикс имении миграции, например 0003, до тех пор пока он уникален для этого приложения. Использование нулевой миграции (т.е. zero) отменит все примененные миграции для данного приложения.

Примечание: данный способ можно использовать для отката изменений схемы базы данных. Но нужно быть внимательным при использовании данного механизма, т.к. в случае если в откатываемых таблицах или колонках были данные, то они могут быть утеряны. Обязательно делайте копию базы данных.

Полезные опции для данной команды, которые можно использовать:

--database DATABASE

Определяет базу данных к которой будут применяться миграции. По умолчанию используется дефолтная.

--fake

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

--plan

Показывает операции миграций, которые будут исполнены при выполнении указанной команды migrate.

--check

Команда завершает работу с ненулевым результатом, когда обнаруживаются не примененные миграции.

Команда sqlmigrate

В случае если необходимо увидеть какой SQL код будет сгенерирован для конкретной миграции, можно использовать команду sqlmigrate.

django-admin sqlmigrate app_label migration_name

Данная команда требует активного подключения к базе данных, которое будет использовано для того, чтобы разрешить имена ограничений (to resolve constraint names). Это означает, что SQL код, вносящий изменения в базу данных, будет сгенерирован по отношению к копии базы данных, к которой планируется применить эти изменения.

Полезные опции для данной команды:

--backwards

Генерирует SQL код для отмены примененных миграций. По умолчанию, SQL генерируется в направлении применения изменений, а не отката.

--database DATABASE

Определяет базу данных, которая по отношению к которой генерируется SQL код. По умолчанию используется дефолтная база данных.

Команда showmigrations

Синтаксис команды:

django-admin showmigrations [app_label [app_label ...]]

Команда позволяет увидеть все миграции текущего проекта. Данную команду можно использовать одним из двух способов, которые определяются одной из опций ниже:

--list, -l

Данная опция является используемой по умолчанию. Она показывает список всех миграций для каждого приложения, а также показывает применена ли данная миграция (помечается символами [X]) или нет. Пример вывода в консоль после использования данной команды можно посмотреть ниже:

admin
     [X] 0001_initial
     [X] 0002_logentry_remove_auto_add
     [X] 0003_logentry_add_action_flag_choices

auth
     [X] 0001_initial
     [X] 0002_alter_permission_name_max_length
     [X] 0003_alter_user_email_max_length
     [X] 0004_alter_user_username_opts

blog
     [X] 0001_initial
     [X] 0002_post_image_url

contenttypes
     [X] 0001_initial
     [X] 0002_remove_content_type_name

dailyAnalysis
     [X] 0001_initial
     [X] 0002_auto_20200518_1608
     [] 0003_image

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

--plan, -p

Показывает план миграций, которому Django будет следовать применяя миграции. Также как и при использовании --list примененные миграции помечаются символами [X].

Использование аргумента app_labels ограничивает вывод только указанными приложениями, однако зависимые миграции из других приложений также могут быть включены в вывод.

--database DATABASE

Опция database определяет базу данных, которую мы хотим исследовать. По умолчанию используется дефолтная база.

В заключении

В официальной документации есть примеры использования двух вариантов следующих конструкций:

django-admin makemigrations
python manage.py makemigrations

Давайте разберемся почему. django-admin это утилита для командной строки для административных задач. Также для любого проекта Django автоматически создается файл manage.py. Он делает те же самые вещи, что и django-admin, а также устанавливает переменную среды DJANGO_SETTINGS_MODULE, которая в свою очередь указывает на файл настроек проекта settings.py.

Тэги:

python

Дата публикации:

21.09.2023

master

Admin