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

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

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_related_name

Options.default_related_name

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

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

get_latest_by

Options.get_latest_by

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

Пример:

get_latest_by = "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']

Порядок сортировки по умолчанию также влияет на запросы агрегации.

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

unique_together

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

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

index_together = [
    ["pub_date", "deadline"],
]

Этот список полей будет индексироваться вместе (т.е., будет выдан соответствующий CREATE INDEX оператор).

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

index_together = ["pub_date", "deadline"]

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