миграции django что это

Миграции

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

Django ORM пользуется моделями данных для общения с БД. Но что, если модели захотелось поменять? Для этого программисты придумали миграции.

Миграция — это описание изменений, которые вы хотите внести в таблицы базы данных. Например, у вас есть модель поста в блоге. У модели Post есть только поле text :

Теперь вы захотели добавить новое поле title — заголовок поста:

Просто поменять файл models.py недостаточно. Работа с базой данных — тонкое дело. Для того, чтобы в базе данных произошли изменения, нужно её отмигрировать, т.е. создать миграцию, которая объяснит базе данных, как ей измениться.

blank=True мы добавили для того, чтобы не случилось конфликта, о котором мы говорим в этой статье.

Что же это такое

Каждая миграция — это файл с инструкциями для базы данных. Все они пронумерованы по порядку:

Никто эти файлы не писал, они создаются автоматически, когда вы запускаете команду makemigrations (о ней будет ниже). Запустив makemigrations для примера выше, вы получите такую миграцию:

Давайте по кусочкам разберём, что тут написано:

Второй большой блок — это operations. В нём лежит описание всех изменений, которые нужно провести в БД:

makemigrations

Если вы уже проводили миграции в своём проекте, то Django сравнит текущий файл models.py с историей миграций. Django сама определит, что нужно убрать из моделей, а что — добавить, чтобы отмигрировать базу данных к новым моделям.

migrate

Команда python manage.py migrate запускает миграции в базе данных. В процессе их исполнения вы увидите такой вывод:

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

Что читать

Попробуйте бесплатные уроки по Python

Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.

Переходите на страницу учебных модулей «Девмана» и выбирайте тему.

Источник

Миграции¶

Команды¶

Есть несколько команд, которые вы будете использовать для взаимодействия с миграциями и обработкой Django схемы базы данных:

Файлы миграции для каждого приложения находятся в каталоге «migrations» внутри этого приложения и предназначены для передачи и распространения как часть его кодовой базы. Вы должны сделать их один раз на своей машине разработки, а затем запустить те же миграции на машинах ваших коллег, ваших промежуточных машинах и, в конечном итоге, ваших производственных машинах.

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

Поддержка бэкэндов¶

Миграции поддерживаются на всех бэкэндах, с которыми поставляется Django, а также в любых сторонних бэкэндах, если они запрограммированы на поддержку изменения схемы (выполняется с помощью класса SchemaEditor ).

Однако некоторые базы данных более эффективны, чем другие, когда дело доходит до миграции схемы; некоторые из предостережений описаны ниже.

PostgreSQL¶

MySQL¶

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

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

SQLite¶

В SQLite небольшие возможности встроенной поддержки изменения схемы, поэтому Django пытается имитировать ее:

Этот процесс обычно работает хорошо, но может быть медленным и иногда давать сбои. Не рекомендуется запускать и переносить SQLite в производственной среде, если вы не очень осведомлены о рисках и его ограничениях; поддержка, с которой поставляется Django, позволяет разработчикам использовать SQLite на своих локальных машинах для разработки менее сложных проектов Django без необходимости в полной базе данных.

Рабочий процесс¶

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

Контроль версий¶

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

Транзакции¶

В базах данных, поддерживающих транзакции DDL (SQLite и PostgreSQL), все операции миграции по умолчанию будут выполняться внутри одной транзакции. Напротив, если база данных не поддерживает транзакции DDL (например, MySQL, Oracle), все операции будут выполняться без транзакции.

Зависимости¶

Файлы миграции¶

Миграции сохраняются в формате на диске, называемом здесь «файлами миграции». Эти файлы на самом деле являются обычными файлами Python с согласованным макетом объектов, написанными в декларативном стиле.

Базовый файл миграции выглядит так:

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

Пользовательские поля¶

Менеджеры модели¶

Если вы используете функцию from_queryset() для динамического создания класса менеджера, вам необходимо наследовать от сгенерированного класса, чтобы сделать его импортируемым:

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

Начальные миграции¶

Первоначальные миграции помечаются атрибутом класса initial=True в классе миграции. Если initial атрибут класса не найден, миграция будет считаться «начальной», если это первая миграция в приложении (т.е. если она не зависит от какой-либо другой миграции в том же приложении).

Согласованность истории¶

Как обсуждалось ранее, вам может потребоваться вручную линеаризовать миграции при объединении двух ветвей разработки. При редактировании зависимостей миграции вы можете непреднамеренно создать несогласованное состояние истории, когда миграция была применена, но некоторые из ее зависимостей нет. Это явный признак того, что зависимости неверны, поэтому Django откажется выполнять миграции или делать новые миграции, пока они не будут исправлены. При использовании нескольких баз данных вы можете использовать метод allow_migrate() из маршрутизация баз данных для контроля того, для каких баз данных makemigrations проверяет согласованную историю.

Добавление миграций в приложения¶

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

Если в вашем приложении уже есть модели и таблицы базы данных и еще нет миграций (например, вы создали его для предыдущей версии Django), вам необходимо преобразовать его для использования миграции, запустив:

Обратите внимание, что это работает только с учетом двух вещей:

Отмена миграций¶

Если вы хотите отменить все миграции, примененные к приложению, используйте имя zero :

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

Исторические модели¶

Когда вы запускаете миграции, Django работает с историческими версиями ваших моделей, хранящимися в файлах миграции. Если вы пишете код Python с помощью операции RunPython или если у вас есть методы allow_migrate на маршрутизаторах базы данных, вам необходимо использовать эту историческую модель версии, а не импортировать их напрямую.

Если вы импортируете модели напрямую, а не используете исторические модели, ваши миграции могут работать изначально, но не будут работать в будущем, когда вы попытаетесь повторно запустить старые миграции (обычно, когда вы настраиваете новую установку и выполняете все миграции для настройки базы данных).

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

Поскольку сериализовать произвольный код Python невозможно, в этих исторических моделях не будет никаких пользовательских методов, которые вы определили. Однако у них будут одинаковые поля, отношения, менеджеры (только те, у которых есть use_in_migrations = True ) и опции Meta (также версионные, поэтому они могут отличаться от ваших текущих).

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

Чтобы удалить старые ссылки, вы можете использовать squash migrations или, если ссылок немного, скопировать их в файлы миграции.

Рекомендации при удалении полей модели¶

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

Добавьте атрибут system_check_deprecated_details в поле вашей модели, как показано ниже:

После периода устаревания по вашему выбору (два или три выпуска функций для полей в самом Django) измените атрибут system_check_deprecated_details на system_check_removed_details и обновите словарь, аналогичный:

Миграция данных¶

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

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

Для начала создайте пустой файл миграции, с которым вы можете работать (Django поместит файл в нужное место, предложит имя и добавит зависимости за вас):

Затем откройте файл; это должно выглядеть примерно так:

Напишем миграцию, которая заполняет наше новое поле name комбинированными значениями first_name и last_name (мы опомнились и поняли, что не у всех есть имя и фамилия). Все, что нам нужно сделать, это использовать историческую модель и перебирать строки:

Как только это будет сделано, мы можем запустить python manage.py migrate как обычно, и миграция данных будет выполняться на месте вместе с другими миграциями.

Доступ к моделям из других приложений¶

Более продвинутые миграции¶

Сжатие миграций¶

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

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

Затем вы должны перевести сжатую миграцию на нормальную миграцию:

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

Сериализация значений¶

Django может сериализовать следующее:

Django не может сериализовать:

Пользовательские сериализаторы¶

Вы можете сериализовать другие типы, написав собственный сериализатор. Например, если бы Django не сериализовал Decimal по умолчанию, вы могли бы сделать это:

Метод serialize() вашего сериализатора должен возвращать строку о том, как значение должно отображаться в миграциях, и набор любых операций импорта, которые необходимы в миграции.

Добавление метода deconstruct() ¶

Django запишет значение как экземпляр вашего класса с заданными аргументами, аналогично тому, как он записывает ссылки на поля Django.

Поддержка нескольких версий Django¶

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

Система миграции будет поддерживать обратную совместимость в соответствии с той же политикой, что и остальная часть Django, поэтому файлы миграции, созданные в Django X.Y, должны работать без изменений в Django X.Y+1. Однако система миграции не обещает прямой совместимости. Могут быть добавлены новые функции, а файлы миграции, созданные с помощью более новых версий Django, могут не работать в более старых версиях.

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

Источник

Миграции ¶

Команды ¶

Есть несколько команд, которые вы будете использовать для взаимодействия с миграциями и обработкой схемы базы данных Django:

Файлы миграции для каждого приложения находятся в каталоге «миграции» внутри этого приложения и предназначены для передачи и распространения как часть его кодовой базы. Вы должны сделать их один раз на своей машине разработки, а затем запустить те же миграции на машинах ваших коллег, ваших промежуточных машинах и, в конечном итоге, ваших производственных машинах.

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

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

Бэкэнд-поддержка ¶

Миграции поддерживаются на всех бэкэндах, с которыми поставляется Django, а также в любых сторонних бэкэндах, если они запрограммированы на поддержку изменения схемы (выполняется через класс SchemaEditor ).

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

PostgreSQL ¶

MySQL ¶

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

Наконец, MySQL имеет относительно небольшие ограничения на длину имен для столбцов, таблиц и индексов, а также ограничение на объединенный размер всех столбцов, покрываемых индексом. Это означает, что индексы, которые возможны на других серверах, не будут созданы в MySQL.

SQLite ¶

В SQLite очень мало встроенной поддержки изменения схемы, поэтому Django пытается имитировать ее:

Этот процесс обычно работает хорошо, но может быть медленным и иногда давать сбои. Не рекомендуется запускать и переносить SQLite в производственной среде, если вы не очень осведомлены о рисках и его ограничениях; поддержка, с которой поставляется Django, позволяет разработчикам использовать SQLite на своих локальных машинах для разработки менее сложных проектов Django без необходимости в полной базе данных.

Рабочий процесс ¶

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

Контроль версий ¶

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

Транзакции ¶

В базах данных, поддерживающих транзакции DDL (SQLite и PostgreSQL), все операции миграции по умолчанию будут выполняться внутри одной транзакции. Напротив, если база данных не поддерживает транзакции DDL (например, MySQL, Oracle), все операции будут выполняться без транзакции.

Зависимости ¶

Это означает, что когда вы запускаете миграции, authors сначала выполняется миграция и создается таблица со ForeignKey ссылками, а затем миграция, которая заставляет ForeignKey столбец запускаться после этого и создает ограничение. Если этого не произошло, миграция попытается создать ForeignKey столбец без таблицы, на которую он ссылается, существующей, и ваша база данных выдаст ошибку.

Файлы миграции ¶

Миграции сохраняются в формате на диске, называемом здесь «файлами миграции». Эти файлы на самом деле являются обычными файлами Python с согласованным макетом объектов, написанными в декларативном стиле.

Базовый файл миграции выглядит так:

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

Пользовательские поля ¶

Модельные менеджеры ¶

При желании вы можете сериализовать менеджеров в миграции и сделать их доступными в RunPython операциях. Это делается путем определения use_in_migrations атрибута в классе менеджера:

Если вы используете from_queryset() функцию для динамического создания класса менеджера, вам необходимо унаследовать от сгенерированного класса, чтобы сделать его импортируемым:

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

Начальные миграции ¶

Первоначальные миграции помечаются атрибутом класса в классе миграции. Если атрибут класса не найден, миграция будет считаться «начальной», если это первая миграция в приложении (т. Е. Если она не зависит от какой-либо другой миграции в том же приложении). initial = True initial

Согласованность истории ¶

Как обсуждалось ранее, вам может потребоваться вручную линеаризовать миграции при объединении двух ветвей разработки. При редактировании зависимостей миграции вы можете непреднамеренно создать несогласованное состояние истории, в котором миграция была применена, но некоторые из ее зависимостей нет. Это явный признак того, что зависимости неверны, поэтому Django откажется выполнять миграции или делать новые миграции, пока они не будут исправлены. При использовании нескольких баз данных вы можете использовать allow_migrate() метод маршрутизаторов баз данных, чтобы контролировать, какие базы данных makemigrations проверяют согласованную историю.

Добавление миграций в приложения ¶

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

Если в вашем приложении уже есть модели и таблицы базы данных и еще нет миграций (например, вы создали его для предыдущей версии Django), вам необходимо преобразовать его для использования миграции, запустив:

Обратите внимание, что это работает только с учетом двух вещей:

Отмена миграции ¶

Если вы хотите отменить все миграции, примененные к приложению, используйте имя zero :

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

Исторические модели ¶

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

Если вы импортируете модели напрямую, а не используете исторические модели, ваши миграции могут работать изначально, но не удастся в будущем, когда вы попытаетесь повторно запустить старые миграции (обычно, когда вы настраиваете новую установку и выполняете все миграции, чтобы установить вверх по базе данных).

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

Поскольку сериализовать произвольный код Python невозможно, в этих исторических моделях не будет никаких пользовательских методов, которые вы определили. Однако у них будут те же поля, отношения, менеджеры (только те, у которых есть ) и параметры (также версионные, поэтому они могут отличаться от ваших текущих). use_in_migrations = True Meta

Это означает, что у вас НЕ будет настраиваемых save() методов, вызываемых для объектов, когда вы обращаетесь к ним в миграциях, и у вас НЕ будет никаких настраиваемых конструкторов или методов экземпляра. Планируйте правильно!

Ссылки на функции в параметрах полей, таких как upload_to и, limit_choices_to и объявления диспетчера моделей с менеджерами, которые имеют, сериализованы в миграциях, поэтому функции и классы необходимо будет хранить до тех пор, пока существует миграция, ссылающаяся на них. Любые настраиваемые поля модели также необходимо сохранить, поскольку они импортируются напрямую путем миграции. use_in_migrations = True

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

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

Рекомендации при удалении полей модели ¶

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

Добавьте system_check_deprecated_details атрибут в поле вашей модели, как показано ниже:

После периода прекращения поддержки по вашему выбору (два или три выпуска функций для полей в самом Django) измените system_check_deprecated_details атрибут на system_check_removed_details и обновите словарь, аналогично:

Перенос данных ¶

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

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

Для начала создайте пустой файл миграции, с которым вы можете работать (Django поместит файл в нужное место, предложит имя и добавит зависимости за вас):

Затем откройте файл; это должно выглядеть примерно так:

Давайте напишем миграцию, которая заполняет наше новое name поле объединенными значениями first_name и last_name (мы опомнились и поняли, что не у всех есть имя и фамилия). Все, что нам нужно сделать, это использовать историческую модель и перебирать строки:

Как только это будет сделано, мы сможем работать в обычном режиме, и миграция данных будет выполняться на месте вместе с другими миграциями. python manage.py migrate

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

Доступ к моделям из других приложений ¶

Более сложные миграции ¶

Сжатие миграций ¶

Вам предлагается свободно выполнять миграции и не беспокоиться о том, сколько их у вас есть; код миграции оптимизирован для работы с сотнями одновременно без особого замедления. Однако, в конце концов, вы захотите вернуться от нескольких сотен миграций к нескольким, и вот тут-то и пригодится раздавливание.

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

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

Затем вы должны перейти от сжатой миграции к нормальной миграции с помощью:

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

Сериализация значений ¶

Django может сериализовать следующее:

Добавлена ​​поддержка сериализации для чистых и конкретных объектов пути из экземпляров pathlib и os.PathLike экземпляров.

Django не может сериализовать:

Пользовательские сериализаторы ¶

Вы можете сериализовать другие типы, написав собственный сериализатор. Например, если Django не Decimal выполняет сериализацию по умолчанию, вы можете сделать это:

serialize() Метод вашего сериализатора должен возвращать строку как значение должно появиться в миграции и набор любого импорта, которые необходимы в процессе миграции.

Добавление deconstruct() метода ¶

Вы можете позволить Django сериализовать ваши собственные экземпляры пользовательского класса, предоставив классу deconstruct() метод. Он не принимает аргументов и должен возвращать кортеж из трех вещей : (path, args, kwargs)

Это возвращаемое значение отличается от deconstruct() метода для настраиваемых полей, который возвращает кортеж из четырех элементов.

Django запишет значение как экземпляр вашего класса с заданными аргументами, аналогично тому, как он записывает ссылки на поля Django.

Чтобы предотвратить создание новой миграции при каждом makemigrations запуске, вы также должны добавить __eq__() метод в декорированный класс. Эта функция будет вызываться платформой миграции Django для обнаружения изменений между состояниями.

Поскольку все аргументы конструктора вашего класса сами по себе сериализуемы, вы можете использовать @deconstructible декоратор класса из, django.utils.deconstruct чтобы добавить deconstruct() метод:

Декоратор добавляет логику для захвата и сохранения аргументов на пути к вашему конструктору, а затем возвращает эти аргументы именно тогда, когда вызывается deconstruct ().

Поддержка нескольких версий Django ¶

Система миграции будет поддерживать обратную совместимость в соответствии с той же политикой, что и остальная часть Django, поэтому файлы миграции, созданные в Django XY, должны запускаться без изменений в Django X.Y + 1. Однако система миграции не обещает прямой совместимости. Могут быть добавлены новые функции, а файлы миграции, созданные в более новых версиях Django, могут не работать в более старых версиях.

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

Источник