Как удалить файлы миграции django

Обновлено: 01.07.2024

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

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

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

Если вам нужен пустой файл миграции для записи собственных объектов Operation , используйте python manage.py makemigrations --empty yourappname , но имейте в виду, что добавление операций изменения схемы вручную может сбить с толку автодетектор миграции и выполнение запуска makemigrations может вывести неверный код.

Все основные операции Django доступны из модуля django.db.migrations.operations .

Вводный материал смотрите в Руководство по миграциям .

Операции для схем¶

CreateModel ¶

class CreateModel ( name , fields , options = None , bases = None , managers = None ) [исходный код] ¶

Создает новую модель в истории проекта и соответствующую таблицу в базе данных.

name - это название модели, которое должно быть записано в файле models.py .

options - это необязательный словарь значений из класса Meta модели.

base - это необязательный список других классов, от которых наследуется эта модель; он может содержать как объекты класса, так и строки в формате appname.ModelName , если вы хотите зависеть от другой модели (чтобы вы унаследовали от исторической версии). Если он не указан, по умолчанию он унаследован от стандартной модели models.Model .

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

DeleteModel ¶

Удаляет модель из истории проекта и ее таблицу из базы данных.

RenameModel ¶

Переименовывает модель со старого имени на новое.

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

AlterModelTable ¶

Изменяет имя таблицы модели (параметр db_table в подклассе Meta ).

AlterUniqueTogether ¶

Изменяет набор уникальных ограничений модели (параметр unique_together в подклассе Meta ).

AlterIndexTogether ¶

Изменяет набор пользовательских индексов модели (параметр index_together в подклассе Meta )

AlterOrderWithRespectTo ¶

class AlterOrderWithRespectTo ( name , order_with_respect_to ) [исходный код] ¶

Создает или удаляет столбец _order , необходимый для параметра order_with_respect_to в подклассе Meta .

AlterModelOptions ¶

Сохраняет изменения различных параметров модели (настройки в Meta модели), например permissions и verbose_name . Не влияет на базу данных, но сохраняет эти изменения для использования экземпляров RunPython . options должен быть словарём, отображающим имена опций для значений.

AlterModelManagers ¶

Изменяет менеджеров, доступных во время миграции.

AddField ¶

class AddField ( model_name , name , field , preserve_default = True ) [исходный код] ¶

Добавляет поле в модель. model_name - это имя модели, name - имя поля, а field - несвязанный экземпляр Field (то, что вы бы поместили в объявление поля в models.py - например, models.IntegerField(null=True) .

Аргумент preserve_default указывает, является ли значение поля по умолчанию постоянным и должно ли оно быть записано в состояние проекта ( True ), или оно является временным и только для этой миграции ( False ) - обычно потому что миграция добавляет в таблицу поле, не допускающее значения NULL, и требует значения по умолчанию для помещения в существующие строки. Это не влияет на поведение установки значений по умолчанию в базе данных напрямую - Django никогда не устанавливает значения по умолчанию для базы данных и всегда применяет их в коде Django ORM.

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

Добавьте поле, допускающее значение NULL, без значения по умолчанию и выполните команду makemigrations . Это должно вызвать миграцию с операцией AddField .
Добавьте в свое поле значение по умолчанию и выполните команду makemigrations . Это должно вызвать миграцию с операцией AlterField .

RemoveField ¶

Удаляет поле из модели.

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

AlterField ¶

class AlterField ( model_name , name , field , preserve_default = True ) [исходный код] ¶

Изменяет определение поля, включая изменения его типа, null , unique , db_column и другие атрибуты поля.

Аргумент preserve_default указывает, является ли значение поля по умолчанию постоянным и должно ли оно быть записано в состояние проекта ( True ), или оно временное и предназначено только для этой миграции ( False ) - обычно потому что миграция изменяет поле, допускающее значение NULL, на поле, не допускающее значения NULL, и требует значения по умолчанию для помещения в существующие строки. Это не влияет на поведение установки значений по умолчанию в базе данных напрямую - Django никогда не устанавливает значения по умолчанию для базы данных и всегда применяет их в коде Django ORM.

Обратите внимание, что не все изменения возможны во всех базах данных - например, вы не можете изменить поле текстового типа, такое как models.TextField() , в поле числового типа, например models.IntegerField() в большинстве базы данных.

RenameField ¶

Изменяет имя поля (и, если не задано db_column , имя его столбца).

AddIndex ¶

Создает индекс в таблице базы данных для модели с именем model_name . index - это экземпляр класса Index .

RemoveIndex ¶

Удаляет индекс с именем name из модели с model_name .

AddConstraint ¶

Создает constraint в таблице базы данных для модели с именем model_name .

RemoveConstraint ¶

Удаляет ограничение с именем name из модели с model_name .

Специальные операции¶

RunSQL ¶

class RunSQL ( sql , reverse_sql = None , state_operations = None , hints = None , elidable = False ) [исходный код] ¶

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

sql и reverse_sql , если они указаны, должны быть строками SQL для запуска в базе данных. В большинстве бэкэндов баз данных (всех, кроме PostgreSQL) Django разбивает SQL на отдельные операторы перед их выполнением.

В PostgreSQL и SQLite используйте только BEGIN или COMMIT в вашем SQL в неатомарных миграциях , чтобы не нарушать состояние транзакции Django.

Вы также можете передать список строк или двух кортежей. Последний используется для передачи запросов и параметров так же, как cursor.execute() . Эти три операции эквивалентны:

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

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

Если reverse_sql равно None (по умолчанию), операция RunSQL необратима.

Аргумент state_operations позволяет вам предоставлять операции, эквивалентные SQL с точки зрения состояния проекта. Например, если вы вручную создаете столбец, вы должны передать сюда список, содержащий операцию AddField , чтобы автодетектор по-прежнему имел актуальное состояние модели. Если вы этого не сделаете, при следующем запуске makemigrations он не увидит никаких операций, добавляющих это поле, и попытается запустить его снова. Например:

Необязательный аргумент hints будет передан как **hints в метод allow_migrate() маршрутизаторов баз данных, чтобы помочь им в принятии решений о маршрутизации. Смотрите Подсказки для получения более подробной информации о подсказках базы данных.

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

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

RunPython ¶

class RunPython ( code , reverse_code = None , atomic = None , hints = None , elidable = False ) [исходный код] ¶

Запускает собственный код Python в историческом контексте. code (и reverse_code , если он указан) должны быть вызываемыми объектами, которые принимают два аргумента; первый - это экземпляр django.apps.registry.Apps , содержащий исторические модели, которые соответствуют месту операции в истории проекта, а второй - экземпляр SchemaEditor .

Аргумент reverse_code вызывается, когда миграции не применяются. Этот вызываемый объект должен отменить то, что сделано в вызываемом code , чтобы миграция была обратимой. Если reverse_code равен None (по умолчанию), операция RunPython необратима.

Необязательный аргумент hints будет передан как **hints в метод allow_migrate() маршрутизаторов баз данных, чтобы помочь им принять решение о маршрутизации. Смотрите Подсказки для получения более подробной информации о подсказках базы данных.

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

Рекомендуется написать код как отдельную функцию над классом Migration в файле миграции и передать его в RunPython . Вот пример использования RunPython для создания некоторых начальных объектов в модели Country :

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

Подобно RunSQL , убедитесь, что если вы меняете схему внутри здесь, вы либо делаете это за пределами системы модели Django (например, триггеры), либо используете SeparateDatabaseAndState для добавления операций, которые будет отражать ваши изменения в состоянии модели - в противном случае версионный ORM и автодетектор перестанут работать правильно.

По умолчанию RunPython запускает свое содержимое внутри транзакции в базах данных, которые не поддерживают транзакции DDL (например, MySQL и Oracle). Это должно быть безопасно, но может вызвать сбой, если вы попытаетесь использовать schema_editor , предоставленный этими бэкэндами; в этом случае передайте atomic=False операции RunPython.

В базах данных, которые действительно поддерживают транзакции DDL (SQLite и PostgreSQL), операции RunPython не содержат автоматически добавляемых транзакций, кроме транзакций, созданных для каждой миграции. Таким образом, в PostgreSQL, например, вам следует избегать объединения изменений схемы и операций RunPython в одной миграции, иначе вы можете столкнуться с такими ошибками, как OperationalError: невозможно ALTER TABLE "mytable", потому что у него есть отложенные триггерные события .

Если у вас другая база данных и вы не уверены, поддерживает ли она транзакции DDL, проверьте атрибут django.db.connection.features.can_rollback_ddl .

Если операция RunPython является частью неатомарные миграции , операция будет выполняться в транзакции, только если atomic=True будет передано в RunPython .

RunPython не меняет за вас соединение моделей волшебным образом; любые методы модели, которые вы вызываете, перейдут в базу данных по умолчанию, если вы не дадите им текущий псевдоним базы данных (доступен из schema_editor.connection.alias , где schema_editor - второй аргумент вашей функции).

Передайте метод RunPython.noop в code или reverse_code , если вы хотите, чтобы операция ничего не делала в заданном направлении. Это особенно полезно для того, чтобы сделать операцию обратимой.

SeparateDatabaseAndState ¶

class SeparateDatabaseAndState ( database_operations = None , state_operations = None ) [исходный код] ¶

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

Он принимает два списка операций. Когда его попросят применить состояние, он будет использовать список state_operations (это обобщенная версия аргумента state_operations в RunSQL ). Когда вас попросят применить изменения к базе данных, он будет использовать список database_operations .

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

Пример использования SeparateDatabaseAndState смотрите в разделе change-a-manytomanyfield-to-use-a-through-model .

Собственный код¶

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

Вы можете взять этот шаблон и работать с ним, хотя мы предлагаем взглянуть на встроенные операции Django в django.db.migrations.operations - они охватывают множество примеров использования полувнутренних аспектов миграции фреймворка, такие как ProjectState , и шаблоны, используемые для получения исторических моделей, а также ModelState и шаблоны, используемые для изменения исторических моделей в state_forwards() .

Вам не нужно слишком много знать о ProjectState , чтобы писать миграции; просто знайте, что у него есть свойство apps , которое дает доступ к реестру приложений (который вы затем можете вызвать с помощью get_model ).

И database_forwards , и database_backwards получают два состояния, переданных им; они представляют разницу, которую применил бы метод state_forwards , но даны вам для удобства и скорости.

Если вы хотите работать с классами модели или экземплярами модели из аргумента from_state в database_forwards() или database_backwards() , вы должны отображать состояния модели с помощью clear_delayed_apps_cache() способ сделать связанные модели доступными:

to_state в методе database_backwards - это более старое состояние; то есть то, которое будет текущим состоянием после завершения реверсирования миграции.

Вы можете встретить реализации reference_model во встроенных операциях; это часть кода автоопределения и не имеет значения для пользовательских операций.

По соображениям производительности экземпляры Field в ModelState.fields повторно используются при миграции. Вы никогда не должны изменять атрибуты этих экземпляров. Если вам нужно изменить поле в state_forwards() , вы должны удалить старый экземпляр из ModelState.fields и добавить на его место новый. То же самое верно для экземпляров Manager в ModelState.managers .

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

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

Приложение имеет 14 различных папок "миграции".

Вот как выглядят некоторые из них:

Безопасно ли удалять все содержимое из каждой из этих папок? Или мне нужно обязательно удалить некоторые из файлов - и если да, то какие файлы?

3 ответа

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

Чтобы отменить миграцию, вы должны сделать следующее:

Используйте python manage.py migrate your_app_name XXXX на случай, если вы хотите отменить миграцию после миграции XXXX. В противном случае используйте python manage.py migrate your_app_name zero , чтобы полностью отменить все миграции.

Удалите файлы .pyc из / migrations / __ pycache __ /, которые вы не применили.

Удалите файлы .py из миграций / которые вы не применили.

Теперь вы можете создавать новые миграции без головной боли.

Если вам нужно объединить все миграции в одну, выполните описанные выше шаги, удалив все миграции, а затем запустите python manage.py makemigrations your_app_name , чтобы создать один файл миграции. После этого просто запустите python manage.py migrate your_app_name и все готово.

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

Если у вас нет постоянных баз данных, тогда да, вы можете удалить все миграции, запустить python manage.py makemigrations --initial , и он создаст новые миграции на основе ваших текущих моделей.

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

Файлы .pyc, как правило, безопасны для удаления при условии, что соответствующие файлы .py все еще там.

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

Я проверил, как это. Я создал новый проект Django и инициировал git-репо. Я запустил 3-4 миграции в Django, что привело к 3-4 файлам миграции в каталоге migrations. Я попытался удалить очень старые файлы миграции (т. Е. 1-й и 2-й файлы миграции) и попытался запустить

Что приводит к некоторой ошибке типа "файлы миграции не найдены". Позже я сделал git stash, который восстановил удаленные файлы. Теперь я попытался запустить ту же команду снова, и она работала нормально.

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

3 ответа

Ответ "это зависит".

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

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

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

Обычно нецелесообразно удалять файлы миграции, которые были применены к вашей БД, если вы либо не 1) полностью не удалили БД, либо 2) не вернули сначала миграцию.

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

Ответ "Do not delete migration files". Чтобы понять, почему мы не должны удалять файлы миграции, вам нужно понять, как миграция работает в рамках. Миграционные файлы - это история вашей базы данных. Один файл миграции создается на основе файлов миграции, созданных в прошлом. Удаление файлов миграции означает потерю вашей истории. Эта историческая информация записана в таблицу django_migrations в вашей базе данных. если вы удалите файлы миграции, вы получите ошибки зависимости. Итак, Don't try to lose your history by deleting your migration files.

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

Из официальной документации:

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

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

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

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

Сбросить всю базу данных в Django

Если мы используем базу данных SQLite по умолчанию в Django, мы можем удалить файл базы данных db.sqlite3 , а затем удалить все папки migrations во всех приложениях. После удаления папок migrations мы можем переделать миграции и перенести их с помощью двух команд; а именно python manage.py makemigrations и python manage.py migrate .
Если мы используем какую-либо другую реляционную базу данных, такую как PostgreSQL или MySQL, мы можем либо удалить все таблицы с помощью инструмента управления базой данных, такого как pgAdmin , DBeaver и т. Д., Либо вручную, используя командную строку. Или мы можем создать совершенно новую базу данных, а затем подключить ее к нашему проекту Django. Обратите внимание, что в обоих случаях нужно сначала удалить все папки migrations , а затем заново выполнить миграции и, наконец, перенести их.
Другой вариант - использовать команду Django manage.py , чтобы очистить для нас всю базу данных. Команда - python manage.py flush . Опять же, после использования этой команды мы должны удалить все папки migrations , а затем выполнить новые миграции.

Вернуть приложение Django к его старым миграциям

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

Если нам нужно вернуться с какой-то последней миграции, скажем, 0014, на более старую миграцию, скажем, 0008, мы можем использовать следующие команды.

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

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

Сопутствующая статья - Django Migration

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

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

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

Если вам нужен пустой файл миграции для записи ваших собственных объектов Operation , запустите , но имейте в виду, что ручное добавление операций изменения схемы может испортить детектор автоматического переноса и вызвать неправильный код во время последующих запусков. оф . python manage.py makemigrations --empty nom_application makemigrations

Все основные операции Django находятся в модуле django.db.migrations.operations .

Схема операций ¶

CreateModel ¶

класс CreateModel ( имя , поля , параметры = Нет , базы = Нет , менеджеры = Нет ) ¶

Создает новую модель в истории проекта и соответствующую таблицу в базе данных.

name - это имя модели, записанное в файле models.py .

options - необязательный словарь значений, взятых из класса Meta модели.

bases - необязательный список других классов, которые должна унаследовать эта модель; он может содержать как объекты класса, так и строки формата, "nomapp.NomModele" если вы хотите зависеть от другой модели (поэтому вы наследуете ее историческую версию). В случае отсутствия значение по умолчанию наследуется от стандартной модели models.Model .

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

DeleteModel ¶

Удаляет модель из истории проекта и ее таблицы из базы данных.

RenameModel ¶

Переименовывает шаблон со старого имени на новое.

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

AlterModelTable ¶

Изменяет имя таблицы модели (параметр db_table внутреннего класса Meta ).

AlterUniqueTogether ¶

Изменяет набор ограничений уникальности модели (параметр unique_together внутреннего класса Meta ).

AlterIndexTogether ¶

Изменяет набор настраиваемых индексов модели (параметр index_together внутреннего класса Meta ).

AlterOrderWithRespectTo ¶

class AlterOrderWithRespectTo ( name , order_with_respect_to ) ¶

Создает или удаляет _order необходимый столбец для параметра order_with_respect_to внутреннего класса Meta .

AlterModelOptions ¶

Сохраняет изменения в различных параметрах модели (атрибутах класса Meta модели) как permissions или verbose_name . Не влияет на базу данных, но сохраняет эти изменения для использования экземплярами RunPython . options должен быть словарь, сопоставляющий имена параметров с их значениями.

AlterModelManagers ¶

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

AddField ¶

класс AddField ( имя_модели , имя , поле , preserve_default = True ) ¶

Добавляет поле в модель. model_name это имя шаблона, name это имя поля, и field является Field несвязанным экземпляр поля (что бы вы положили в объявлении поля в models.py , например models.IntegerField(null=True) ).

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

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

Добавьте поле с пустым значением, разрешенным без значения по умолчанию, и выполните команду makemigrations . Это должно вызвать миграцию, содержащую операцию AddField .
Добавьте в свое поле значение по умолчанию и выполните команду makemigrations . Это должно вызвать миграцию, содержащую операцию AlterField .

RemoveField ¶

Удаляет поле из модели.

AlterField ¶

класс AlterField ( имя_модели , имя , поле , preserve_default = True ) ¶

Изменяет определение поля, в том числе изменения в его тип, атрибуты null , unique , db_column или другие атрибуты поля.

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

Обратите внимание, что не всегда возможно внести все изменения, в том числе в зависимости от базы данных. Например, невозможно преобразовать поле текстового типа, как models.TextField() в поле числового типа, как models.IntegerField() в большинстве баз данных.

RenameField ¶

Изменяет имя поля (и, если оно db_column не определено, имя столбца).

AddIndex ¶

Создает индекс в таблице базы данных для модели model_name . index является экземпляром класса Index .

RemoveIndex ¶

Удаляет именованный индекс name из модели с именем model_name .

AddConstraint ¶

Создает: doc: `constraint </ ref / models / constraints>` в таблице базы данных для указанной модели model_name .

RemoveConstraint ¶

Удаляет именованное ограничение name из модели с именем model_name .

Специальные операции ¶

RunSQL ¶

класс RunSQL ( SQL , reverse_sql = None , state_operations = None , намеки = нет , elidable = False ) ¶

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

sql , и, reverse_sql если указан, должны быть строками SQL для выполнения в базе данных. Для большинства механизмов баз данных (всех, кроме PostgreSQL) Django разделяет код SQL на отдельные операторы перед их выполнением.

В PostgreSQL и SQLite используйте операторы SQL BEGIN или COMMIT только в неатомарных миграциях , чтобы не нарушать состояние транзакции Django.

Вы также можете передать список строк или двоичных кортежей. Эта последняя опция используется для передачи запросов и параметров по тому же принципу, что и для cursor.execute () . Эти три операции эквивалентны:

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

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

Если reverse_sql есть None (по умолчанию), операция RunSQL необратима.

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

Необязательный параметр hints будет передан как **hints метод allow_migrate() маршрутизаторам баз данных, чтобы помочь им принимать решения о маршрутизации. См. Подсказки для получения дополнительной информации о подсказках базы данных.

Необязательный параметр elidable определяет, будет ли операция подавлена (пропущена) при объединении миграций .

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

RunPython ¶

Класс RunPython ( код , reverse_code = None , атомные = None , намеки = нет , elidable = False ) ¶

Запускает собственный код Python в историческом контексте. code (и reverse_code если он указан) должны быть исполняемыми объектами, принимающими два параметра; первый - это экземпляр, django.apps.registry.Apps содержащий историзованные модели, которые соответствуют положению операции в истории проекта, а второй - экземпляр SchemaEditor .

Параметр reverse_code вызывается при обращении миграций. Этот исполняемый объект должен отменить то, что было сделано исполняемым объектом, code чтобы эта миграция была обратимой. Если reverse_code есть None (по умолчанию), операция RunPython необратима.

Необязательный параметр hints будет передан как **hints метод allow_migrate() маршрутизаторам базы данных, чтобы помочь им принять решение о маршрутизации. См. Подсказки для получения дополнительной информации о подсказках базы данных.

Необязательный параметр elidable определяет, будет ли операция подавлена (пропущена) при объединении миграций .

Рекомендуется написать код как отдельную функцию поверх класса Migration в файле миграции и передать его в RunPython . Вот пример использования RunPython для создания некоторых исходных объектов модели Country :

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

Как RunSQL и в случае, если вы вносите здесь изменения в схему, будьте осторожны, чтобы сделать это за пределами системы моделей Django (например, с триггерами) или используйте SeparateDatabaseAndState для вставки операций, отражающих ваши изменения в состоянии. моделей. В противном случае версионный ORM и автодетектор могут работать некорректно.

По умолчанию RunPython будет выполнять свое содержимое внутри транзакции для баз данных, которые не поддерживают транзакции DDL (операторы изменения схемы), например MySQL или Oracle. В принципе это работает нормально, но может вызвать сбой, если вы попытаетесь использовать объект, schema_editor предоставляемый этими движками; в этом случае переходите atomic=False к операции RunPython .

Для баз данных, поддерживающих транзакции схемы DDL (SQLite и PostgreSQL), никакие транзакции не добавляются автоматически для операций RunPython за пределами транзакций, созданных для каждой миграции. Так, например, с PostgreSQL, вам следует избегать объединения изменений схемы с операциями RunPython в рамках одной миграции, чтобы избежать таких ошибок . OperationalError: cannot ALTER TABLE "mytable" because it has pending trigger events

Если ваша база данных отличается, и вы не уверены, поддерживает ли она транзакции DDL, проверьте атрибут django.db.connection.features.can_rollback_ddl .

Если операция RunPython является частью неатомарной миграции , операция будет выполняться в транзакции, только если atomic=True она передана в операцию RunPython .

RunPython не меняет волшебным образом подключение моделей для вас; любой вызываемый вами метод шаблона будет направлен в базу данных по умолчанию, если вы не укажете им псевдоним базы данных для использования (доступен в schema_editor.connection.alias , где schema_editor - второй параметр, полученный вашей функцией).

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

SeparateDatabaseAndState ¶

class SeparateDatabaseAndState ( database_operations = None , state_operations = None ) ¶

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

Он принимает два списка операций. На вопрос , чтобы применить изменения состояния, он использует список state_operations (это обобщенный вариант параметра state_operations в RunSQL ). Когда его просят применить изменения базы данных, он использует список database_operations .

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

Написание пользовательских операций ¶

Операции имеют относительно простой API и спроектированы таким образом, чтобы вы могли легко писать подклассы, дополняющие те, которые предоставляет Django. Базовая структура a Operation выглядит так:

Вы можете взять эту модель и расширить ее, хотя мы предлагаем взглянуть на операции, предоставляемые Django в django.db.migrations.operations . Они охватывают большую часть примеров использования ProjectState полувнутренних аспектов миграционной системы, таких как механизмы, используемые для получения историзованных моделей, а также ModelState мотивы, использованные для развития моделей, историзуемых в state_forwards() .

ProjectState Чтобы писать миграции, вам не нужно много знать об этом ; вам просто нужно знать, что у него есть свойство apps , предоставляющее доступ к реестру приложений (по которому вы можете позвонить get_model ).

database_forwards и database_backwards оба получают два состояния; они представляют собой отличие от того, что использовалось state_forwards бы в этом методе , но переданы вам для удобства и ради скорости.

Если вы хотите управлять классами или экземплярами моделей с помощью параметра from_state в database_forwards() или database_backwards() , вы должны создать состояния модели с помощью метода clear_delayed_apps_cache() , чтобы сделать связанные модели доступными:

to_state в методе database_backwards - старшее состояние ; то есть тот, который будет представлять текущее состояние, когда миграция завершит работу по отмене.

Вы можете найти реализации references_model в операциях, предоставляемых Django; это часть кода автоопределения и не играет роли для пользовательских операций.

По соображениям производительности экземпляры Field в ModelState.fields повторно используются от одной миграции к другой. Никогда не трогайте атрибуты этих экземпляров. Если вам нужно развить поле state_forwards() , вы должны удалить старый экземпляр ModelState.fields и добавить на его место новый. Тот же принцип применяется к экземплярам Manager в ModelState.managers .

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

Читайте также: