Опции модели 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"

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 и создать копию существующей модели. Однако для этой ситуации есть лучший подход:: ref:proxy-models.

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, модель, которая является подклассом другой модели, будет рассматриваться как proxy model.

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 существующей строки не видны Джанго. Примером является триггер 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¶

Список 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".

label¶

Options.label¶

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

label_lower¶

Options.label_lower¶

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