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

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"

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 admin и обеспечивается на уровне базы данных (то есть, соответствующие 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'.