Опции Meta

Этот документ описывает все возможные опции метаданных, которые вы можете передать своей модели во внутренний class Meta.

Доступные опции Meta

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'
Названия таблиц
Чтобы сэкономить ваше время, Django автоматически получает имя таблицы базы данных из имени класса вашей модели и приложения, в котором оно содержится. Имя таблицы базы данных модели строится путем соединения «метки приложения» модели – имени, которое вы использовали в manage.py startapp – с именем класса модели с подчеркиванием между ними.

Например, если у вас есть приложение bookstore (созданное с помощью manage.py startapp bookstore), модель, определенная как class Book, будет иметь таблицу базы данных с именем bookstore_book.

Чтобы переопределить имя таблицы базы данных, используйте параметр db_table в class Meta.

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

Используйте строчные имена таблиц для MariaDB и MySQL

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

Экранирование имени таблицы для Oracle

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

db_table = '"name_left_in_lowercase"'
Такие экранированные имена могут также использоваться с другими поддерживаемыми базами данных Django; однако, за исключением Oracle, кавычки не имеют никакого эффекта. Смотрите примечания к Oracle для более подробной информации.

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. Все остальные аспекты работы с моделью такие же, как обычно. Это включает в себя

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

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

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

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

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

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]
Порядок связанных с Question объектов Answer объектов можно установить, передав список первичных ключей 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>
order_with_respect_to неявно устанавливает опцию ordering

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

Изменение order_with_respect_to

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

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)]
Предупреждение

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

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

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, модель, которая является подклассом другой модели, будет рассматриваться как proxy model.

required_db_features
Options.required_db_features
Список функций базы данных, которые должно иметь текущее соединение, чтобы модель рассматривалась на этапе миграции. Например, если вы установите для этого списка значение ['gis_enabled'], модель будет синхронизироваться только в базах данных с поддержкой ГИС. Также полезно пропустить некоторые модели при тестировании с несколькими базами данных. Избегайте отношений между моделями, которые могут или не могут быть созданы, так как ORM не справляется с этим.

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

select_on_save
Options.select_on_save
Определяет, будет ли Django использовать алгоритм pre-1.6 django.db.models.Model.save(). Старый алгоритм использует SELECT, чтобы определить, существует ли существующая строка для обновления. Новый алгоритм пытается UPDATE напрямую. В некоторых редких случаях 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 и применяется на уровне базы данных (т.е. соответствующие операторы UNIQUE включены в оператор CREATE TABLE).

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

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

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

index_together
Options.index_together
Вместо этого используйте параметр indexes.

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

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

index_together = [
["pub_date", "deadline"],
]
Этот список полей будет проиндексирован вместе (то есть будет выполнен соответствующий оператор CREATE INDEX.)

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

index_together = ["pub_date", "deadline"]
constraints
Options.constraints
Список constraints, который вы хотите определить в модели:

from django.db import models

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

class Meta:
constraints = [
models.CheckConstraint(check=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".

Атрибуты Meta только для чтения
label
Options.label
Представление объекта возвращает app_label.object_name, например, 'Polls.Question'.

label_lower
Options.label_lower
Представление модели возвращает app_label.model_name, например, 'Polls.question'.