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

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

Введено в 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.

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

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

unique_together = ("driver", "restaurant")

В уникальном наборе ManyToManyField нельзя включать. (Непонятно, что это вообще означает!) Если вам нужно проверить уникальность, связанную с 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'.