Параметры метаданных модели

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

Доступные 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'

Имена таблиц

Для экономии времени Django автоматически выводит имя таблицы базы данных из имени класса вашей модели и приложения, в котором она находится. Имя таблицы базы данных модели формируется путем объединения «имени приложения» модели — имени, используемого в manage.py startapp — и имени класса модели с помощью подчеркивания.

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

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

Если имя вашей таблицы базы данных является SQL-зарезервированным словом или содержит символы, которые недопустимы в именах переменных Python — в частности, дефис — это допустимо. Django экранирует имена столбцов и таблиц за кулисами.

db_table = '"name_left_in_lowercase"'

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]

Порядок связанных объектов 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>

ordering

Options.ordering

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

ordering = ['-order_date']

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

Например, для упорядочивания по полю pub_date по возрастанию, используйте это:

ordering = ['pub_date']

Чтобы отсортировать по pub_date в убывающем порядке, используйте это:

ordering = ['-pub_date']

Для упорядочивания по pub_date в убывающем порядке, затем по author в возрастающем порядке, используйте это:

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

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

from django.db.models import F

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

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

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'], модель будет синхронизироваться только в базах данных, поддерживающих ГИС. Это также полезно для пропуска некоторых моделей при тестировании с несколькими поставщиками баз данных. Избегайте отношений между моделями, которые могут или могут не быть созданы, так как 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() для получения более подробной информации об старом и новом алгоритме сохранения.

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 admin и применяется на уровне базы данных (т. е., соответствующие 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

Новое в Django 2.2.

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

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