Параметры Meta модели

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.

base_manager_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

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

default_manager_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. Здесь задаются поля, которые по умолчанию будут использоваться в методах Manager модели: latest() и earliest().

Пример:

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

order_with_respect_to

Options.order_with_respect_to

Позволяет упорядочивать объекты относительно указанного поля, обычно ForeignKey. Это можно использовать, чтобы упорядочивать связанные объекты относительно родительского объекта. Например, если Answer связан с объектом Question, у вопроса может быть несколько ответов и порядок ответов имеет значение. В этом случае можно сделать следующее:

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 есть несколько связанных объектов Answer, возвращаемый список содержит первичные ключи связанных объектов Answer:

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

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

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

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

>>> 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"]

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

from django.db.models import F

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

permissions

Options.permissions

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

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

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

default_permissions

Options.default_permissions

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

proxy

Options.proxy

Если proxy = True, модель, наследующая другую модель, будет считаться прокси-моделью.

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. В некоторых редких случаях Django не видит UPDATE существующей строки. Например, это может произойти с триггером PostgreSQL ON UPDATE, который возвращает NULL. В таких случаях новый алгоритм выполнит INSERT, даже если строка существует в базе данных.

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

Подробнее о старом и новом алгоритмах сохранения см. в разделе django.db.models.Model.save().

indexes

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"]]

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

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

unique_together = ["driver", "restaurant"]

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

Исключение ValidationError, возникающее при проверке модели в случае нарушения ограничения, имеет код ошибки unique_together.

constraints

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'.