Создатьмодель¶

class CreateModel(name, fields, options=None, bases=None, managers=None)¶

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

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

fields представляет собой список из двух кортежей (field_name, field_instance). Экземпляр поля должен быть несвязанным полем (то есть просто models.CharField(...), а не полем, взятым из другой модели).

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

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

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

УдалитьМодель¶

class DeleteModel(name)¶

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

ПереименоватьМодель¶

class RenameModel(old_name, new_name)¶

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

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

АльтерМодельТабле¶

class AlterModelTable(name, table)¶

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

АльтерМоделТаблеКоммент¶

class AlterModelTableComment(name, table_comment)¶

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

AlterUniqueTogether¶

class AlterUniqueTogether(name, unique_together)¶

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

АльтерИндексВместе¶

class AlterIndexTogether(name, index_together)¶

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

AlterOrderWithRespectTo¶

class AlterOrderWithRespectTo(name, order_with_respect_to)¶

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

АльтерМодельОптионс¶

class AlterModelOptions(name, options)¶

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

АльтерМодельМенеджеры¶

class AlterModelManagers(name, managers)¶

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

Добавить поле¶

class AddField(model_name, name, field, preserve_default=True)¶

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

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

RemoveField¶

class RemoveField(model_name, name)¶

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

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

АльтерФилд¶

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()», в большинстве баз данных.

ПереименоватьПоле¶

class RenameField(model_name, old_name, new_name)¶

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

ДобавитьИндекс¶

class AddIndex(model_name, index)¶

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

УдалитьИндекс¶

class RemoveIndex(model_name, name)¶

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

ПереименоватьИндекс¶

class RenameIndex(model_name, new_name, old_name=None, old_fields=None)¶

Переименовывает индекс в таблице базы данных для модели с именем model_name. Можно указать только одно из «old_name» и «old_fields». old_fields — это итерация строк, часто соответствующая полям index_together (опция до Django 5.1).

В базах данных, которые не поддерживают оператор переименования индекса (SQLite и MariaDB < 10.5.2), операция приведет к удалению и воссозданию индекса, что может быть дорогостоящим.

AddConstraint¶

class AddConstraint(model_name, constraint)¶

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

Удалить ограничение¶

class RemoveConstraint(model_name, name)¶

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

ВыполнитьSQL¶

class RunSQL(sql, reverse_sql=None, state_operations=None, hints=None, elidable=False)¶

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

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

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

migrations.RunSQL("INSERT INTO musician (name) VALUES ('Reinhardt');")
migrations.RunSQL([("INSERT INTO musician (name) VALUES ('Reinhardt');", None)])
migrations.RunSQL([("INSERT INTO musician (name) VALUES (%s);", ["Reinhardt"])])

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

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

migrations.RunSQL(
    sql=[("INSERT INTO musician (name) VALUES (%s);", ["Reinhardt"])],
    reverse_sql=[("DELETE FROM musician where name=%s;", ["Reinhardt"])],
)

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

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

migrations.RunSQL(
    "ALTER TABLE musician ADD COLUMN name varchar(255) NOT NULL;",
    state_operations=[
        migrations.AddField(
            "musician",
            "name",
            models.CharField(max_length=255),
        ),
    ],
)

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

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

RunSQL.noop¶

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

Запустить Python¶

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:

from django.db import migrations


def forwards_func(apps, schema_editor):
    # We get the model from the versioned app registry;
    # if we directly import it, it'll be the wrong version
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).bulk_create(
        [
            Country(name="USA", code="us"),
            Country(name="France", code="fr"),
        ]
    )


def reverse_func(apps, schema_editor):
    # forwards_func() creates two Country instances,
    # so reverse_func() should delete them.
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).filter(name="USA", code="us").delete()
    Country.objects.using(db_alias).filter(name="France", code="fr").delete()


class Migration(migrations.Migration):
    dependencies = []

    operations = [
        migrations.RunPython(forwards_func, reverse_func),
    ]

Обычно эту операцию вы будете использовать для создания миграций данных, запуска пользовательских обновлений и изменений данных и всего остального, для чего вам нужен доступ к 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.

static RunPython.noop()¶

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

SeparateDatabaseAndState¶

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

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

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

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

Пример использования SeparateDatabaseAndState см. в разделе «Изменение многих полей для использования сквозной модели».