abstract¶

Options.abstract¶

При abstract = True, эта модель будет абстрактной моделью.

app_label¶

Options.app_label¶

Если модель определена вне приложения из INSTALLED_APPS, она должна указать к какому приложению она относится:

app_label = "myapp"

Если вы хотите представить модель в формате app_label.object_name или app_label.model_name, вы можете использовать model._meta.label и model._meta.label_lower соответственно.

verbose_name¶

Options.base_manager_name¶

Имя атрибута менеджера, например 'objects', для использования в _base_manager модели.

db_table¶

Options.db_table¶

Название таблицы в базе данных для этой модели:

db_table = "music_album"

db_table = '"name_left_in_lowercase"'

db_table_comment¶

Options.db_table_comment¶

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

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

db_tablespace¶

Options.db_tablespace¶

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

default_related_name¶

Options.default_manager_name¶

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

default_related_name¶

Options.default_related_name¶

Название, которое будет использоваться для обратных связей к этой модели. По умолчанию <model_name>_set.

Эта опция также устанавливает related_query_name.

Т.к. название поля обратной связи должно быть уникальным, будьте осторожны, если собираетесь наследоваться от модели. Чтобы избежать коллизий в названиях, можно добавить '%(app_label)s' и '%(model_name)s', которые будут заменены соответственно на название приложения модели и название модели в нижнем регистре. Смотрите именование обратных связей для абстрактных моделей.

get_latest_by¶

Options.get_latest_by¶

Название сортируемого поля модели, обычно DateField, DateTimeField или IntegerField. Определяет поле по умолчанию, которое будет использовано методами latest() и earliest() Manager-а модели.

Например:

# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]

Подробности в разделе о latest().

managed¶

Options.managed¶

По умолчанию True, означает что Django создаст необходимые таблицы в базе данных при выполнении команды migrate и удалит их при выполнении flush. То есть Django управляет таблицами.

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

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

2. Если модель с managed=False содержит ManyToManyField на другую неуправляемую модель, промежуточная таблица для хранения связи многое-ко-многим не будет создана. Однако, промежуточная таблица между управляемой и не управляемой моделью будет создана.

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

Правильное создание таблиц при тестировании в тестовой базе данных для модели с managed=False ложится на ваши плечи.

Если вы хотите переопределить поведение модели на уровне Python, вы можете использовать managed=False и создать копию существующей модели. Однако, есть лучшее решение для такой ситуации: Proxy-модели.

order_with_respect_to¶

Options.order_with_respect_to¶

Объекты модели будут отсортированы относительно указанного поля. Почти всегда используется для ForeignKey. Можно использовать для сортировки связанных объектов по значению из родительского объекта. Например, модель Answer``(ответ) связана с моделью ``Question``(вопрос) через ``ForeignKey, вопрос содержит несколько ответов и порядок этих ответов имеет значение:

from django.db import models


class Question(models.Model):
    text = models.TextField()
    # ...


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = "question"

Когда установлен order_with_respect_to, предоставляются два дополнительных метода для получения и установки порядка связанных объектов: get_RELATED_order() и set_RELATED_order(), где RELATED — это имя модели в нижнем регистре. Например, если предположить, что объект «Вопрос» имеет несколько связанных объектов «Ответ», возвращаемый список содержит первичные ключи связанных объектов «Ответ»:

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

Порядок связанных с объектом «Вопрос» объектов «Ответ» можно установить, передав список первичных ключей «Ответ»:

>>> question.set_answer_order([3, 1, 2])

Связанные объекты также получают два метода: get_next_in_order() и get_previous_in_order(), которые можно использовать для доступа к этим объектам в их правильном порядке. Предполагая, что объекты Answer отсортированы по идентификатору:

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

ordering¶

Options.ordering¶

Сортировка по умолчанию используемая при получении объектов:

ordering = ["-order_date"]

Это кортеж или список строк. Каждая строка это название поля с необязательным префиксом «-», который указывает на нисходящую сортировку. Поля без «-» будут отсортированы по возрастанию. Используйте «?» для случайной сортировке.

Например, для сортировки по возрастанию по полю pub_date:

ordering = ["pub_date"]

Нисходящая сортировка по полю pub_date:

ordering = ["-pub_date"]

Для нисходящей сортировки по pub_date и восходящей по author, используйте:

ordering = ["-pub_date", "author"]

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

from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]

permissions¶

Options.permissions¶

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

permissions = [("can_deliver_pizzas", "Can deliver pizzas")]

Это список 2-х элементных кортежей в формате (код разрешения, название разрешения).

default_permissions¶

Options.default_permissions¶

По умолчанию ('add', 'change', 'delete'). Вы можете поменять этот список, например, указав пустой список, если ваше приложение не требует никаких прав доступа. Необходимо указать в модели перед тем, как она будет создана командой migrate.

proxy¶

Options.proxy¶

При proxy = True, модель унаследованная от другой модели будет создана как proxy-модель.

required_db_features¶

Options.required_db_features¶

Список функций базы данных, который необходимы для работы модели. Учитываются при миграции. Например, если указать ['gis_enabled'], таблица для модели будет создана только для базы данных, которая поддерживает GIS. Эта опция также полезна при тестировании на разных базах данных. Избегайте связей между моделями, которые не могут быть созданы в одной базе данных. ORM не умеет обрабатывать такие ситуации.

required_db_vendor¶

Options.required_db_vendor¶

Список поддерживаемых баз данных. Текущий список: sqlite, postgresql, mysql, oracle. Если эта опция не пустая, и база данных не соответствует указанной, таблица для модели не будет создана при миграции.

select_on_save¶

Options.select_on_save¶

Определяет, будет ли Django использовать алгоритм django.db.models.Model.save() версии до 1.6. Старый алгоритм использует SELECT, чтобы определить, существует ли существующая строка, которую нужно обновить. Новый алгоритм пытается выполнить UPDATE напрямую. В некоторых редких случаях UPDATE существующей строки не отображается в Django. Примером может служить триггер PostgreSQL ON UPDATE, который возвращает NULL. В таких случаях новый алгоритм в конечном итоге выполнит INSERT, даже если строка существует в базе данных.

Обычно нет надобности менять эту настройку. По умолчанию равно False.

См. django.db.models.Model.save() для получения дополнительной информации о старом и новом алгоритме сохранения.

index_together¶

Options.indexes¶

Список индексов, которые вы хотите определить в модели:

from django.db import models


class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=["last_name", "first_name"]),
            models.Index(fields=["first_name"], name="first_name_idx"),
        ]

unique_together¶

Options.unique_together¶

Вместо этого используйте UniqueConstraint с опцией constraints.

UniqueConstraint предоставляет больше функциональности, чем unique_together. unique_together может устареть в будущем.

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

unique_together = [["driver", "restaurant"]]

Кортеж кортежей полей, которые должны быть вместе уникальны. Используется в интерфейсе администратора для проверки данных и на уровне базы данных (то есть соответствующее определение UNIQUE будет добавлено в CREATE TABLE запрос).

Для удобства index_together может быть одноуровневым списком, если определяется один набор полей:

unique_together = ["driver", "restaurant"]

ManyToManyField не может быть включен в unique_together. (Непонятно, что это вообще означает!) Если вам нужно проверить уникальность, связанную с ManyToManyField, попробуйте использовать сигнал или явную модель through.

Будет вызвано исключение ValidationError в процессе проверки модели, если проверка ограничений(constraint) вернула ошибку с кодом unique_together.

abstract¶

Options.constraints¶

Список ограничений, которые вы хотите определить в модели:

from django.db import models


class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
        ]

verbose_name¶

Options.verbose_name¶

Читабельное название модели, в единственном числе:

verbose_name = "pizza"

Если не указано, Django создаст из названия модели: CamelCase станет camel case.

verbose_name_plural¶

Options.verbose_name_plural¶

Название модели в множественном числе:

verbose_name_plural = "stories"

Если не указано, Django создаст по правилу verbose_name + "s".

label¶

Options.label¶

Представление объекта, возвращает app_label.object_name, например 'polls.Question'.

label_lower¶

Options.label_lower¶

Представление объекта, возвращает app_label.model_name, например 'polls.question'.