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

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

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 использовать алгоритм 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

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

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.

index_together

Options.index_together

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

index_together = [
    ["pub_date", "deadline"],
]

Этот список полей будет индексироваться вместе (т.е. будет выдан соответствующий CREATE INDEX оператор.)

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

index_together = ["pub_date", "deadline"]

Устарело начиная с версии 4.2: Используйте параметр indexes вместо него.

constraints

Options.constraints

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

from django.db import models


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

    class Meta:
        constraints = [
            models.CheckConstraint(check=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".

Только для чтения Meta атрибуты

label

Options.label

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

label_lower

Options.label_lower

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