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

В данном документе описаны все возможные параметры метаданных, которые вы можете указать для вашей модели в её внутренних 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 по возрастанию и размещения значений NULL в конце используйте следующее:

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, чтобы избежать создания пропущенных разрешений.

Изменено в Django 2.1:

Разрешение view было добавлено.

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 напрямую. В некоторых редких случаях 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'.