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

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

Имя менеджера, используемого для _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() для получения более подробной информации.

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

Добавлена поддержка списка полей.

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 2.0:

Добавлена поддержка выражений запросов.

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'], модель будет синхронизирована только на базах данных, поддерживающих 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

Новое в Django 1.11.

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

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

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

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"]

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