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

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

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

abstract

Options.abstract

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

app_label

Options.app_label

Если модель определена вне приложения в INSTALLED_APPS, она должна указать, к какому приложению она принадлежит:

app_label = 'myapp'

Новая возможность в Django 1.9.

Если вы хотите представить модель в формате app_label.object_name или app_label.model_name, вы можете использовать model._meta.label или model._meta.label_lower соответственно.

base_manager_name

Options.base_manager_name

Новая возможность в Django 1.10.

Имя менеджера, используемого для _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

Новая возможность в Django 1.10.

Имя менеджера, используемого для _default_manager модели.

default_related_name

Options.default_related_name

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

Этот параметр также устанавливает related_query_name.

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

Устарело начиная с версии 1.10: Этот атрибут теперь влияет на related_query_name. Старое имя поиска запроса устарело:

from django.db import models

class Foo(models.Model):
    pass

class Bar(models.Model):
    foo = models.ForeignKey(Foo)

    class Meta:
        default_related_name = 'bars'

>>> bar = Bar.objects.get(pk=1)
>>> # Using model name "bar" as lookup string is deprecated.
>>> Foo.objects.get(bar=bar)
>>> # You should use default_related_name "bars".
>>> Foo.objects.get(bars=bar)

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

Новое в Django 1.9.

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

required_db_vendor

Options.required_db_vendor

Новое в Django 1.9.

Имя поддерживаемого поставщика баз данных, специфическое для этой модели. Текущие встроенные имена поставщиков: 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

Новое в Django 1.9.

Представление объекта, возвращает app_label.object_name, например 'polls.Question'.

label_lower

Options.label_lower

Новое в Django 1.9.

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