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

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

Имя атрибута менеджера, например, 'objects', которое используется для _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_table_comment

Options.db_table_comment

Комментарий к таблице базы данных для этой модели. Это полезно для документирования таблиц базы данных для лиц с прямым доступом к базе данных, которые могут не рассматривать ваш код Django. Например:

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

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() для получения дополнительной информации.

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

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

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

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

Используйте UniqueConstraint с опцией constraints вместо этого.

UniqueConstraint предоставляет больше функциональности, чем unique_together. unique_together может быть устаревшим в будущем.

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

unique_together = [["driver", "restaurant"]]

Это список списков, которые должны быть уникальными при совместном рассмотрении. Используется в Django админ-панели и принудительно на уровне базы данных (т.е. соответствующие UNIQUE инструкции включены в CREATE TABLE инструкцию).

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

unique_together = ["driver", "restaurant"]

ManyToManyField не может быть включен в unique_together. (Непонятно, что это вообще должно означать!) Если вам нужно проверить уникальность, связанную с ManyToManyField, попробуйте использовать сигнал или явную модель through.

Исключение ValidationError возникает при проверке модели, когда ограничение нарушено, с кодом ошибки unique_together.

constraints

Options.constraints

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

from django.db import models


class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
        ]

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