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

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

Доступные Meta параметры

abstract

Options.abstract

Если abstract = True, эта модель будет являться абстрактным базовым классом.

app_label

Options.app_label

Если модель существует вне стандартных расположений (models.py или models пакета в приложении), модель должна определить, к какому приложению она относится:

app_label = 'myapp'

app_label больше не требуется для моделей, определённых вне модуля models приложения.

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)
    # ...

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

select_on_save

Options.select_on_save

Определяет, будет ли Django использовать алгоритм сохранения pre-1.6 django.db.models.Model.save(). Старый алгоритм использует 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 админ-панели и навязывается на уровне базы данных (т.е., соответствующие 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".