Опции Meta модели¶

Если abstract=True, эта модель будет базовым абстрактным классом.

Если модель определена вне приложения INSTALLED_APPS, она должна объявить, какому приложению она принадлежит:

app_label = 'myapp'

Если вы хотите представить модель в формате app_label.object_name или app_label.model_name, вы можете использовать model._meta.label или model._meta.label_lower соответственно.

Имя менеджера, например 'objects', для использования в модели _base_manager.

Имя таблицы базы данных, используемой для модели:

db_table = 'music_album'

Имя табличного пространства базы данных для использования в этой модели. По умолчанию используется настройка проекта DEFAULT_TABLESPACE, если установлена. Если серверная часть не поддерживает табличные пространства, эта опция игнорируется.

Имя менеджера для использования в модели _default_manager.

Имя, которое будет использоваться по умолчанию для отношения от связанного объекта обратно к этому. По умолчанию это <model_name>_set.

Эта опция также устанавливает related_query_name.

Поскольку обратное имя поля должно быть уникальным, будьте осторожны, если вы намереваетесь создать подкласс для своей модели. Чтобы обойти коллизии имен, часть имени должна содержать '%(app_label)s' и '%(model_name)s'), которые заменяются соответственно именем приложения, в котором находится модель и название модели, оба в нижнем регистре. Смотрите параграф связанные имена для абстрактных моделей.

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

По умолчанию True, то есть Django создаст соответствующие таблицы базы данных в migrate или как часть миграции и удалит их как часть команды управления flush. То есть Django управляет жизненными циклами таблиц базы данных.

Если установлено значение False, для этой модели не будут выполняться операции создания, изменения или удаления таблицы базы данных. Это полезно, если модель представляет существующую таблицу или представление базы данных, созданное другими способами. Это единственная разница, когда managed=False. Все остальные аспекты работы с моделью такие же, как обычно. Это включает в себя

1. Добавление автоматического поля первичного ключа в модель, если вы его не объявили. Чтобы избежать путаницы для более поздних читателей кода, рекомендуется указывать все столбцы из таблицы базы данных, которую вы моделируете, при использовании неуправляемых моделей.

2. Если модель с managed=False содержит ManyToManyField, который указывает на другую неуправляемую модель, то промежуточная таблица для объединения «многие ко многим» также не будет создана. Однако промежуточная таблица между одной управляемой и одной неуправляемой моделью будет создана.

   Если вам нужно изменить это поведение по умолчанию, создайте таблицу-посредник в качестве явной модели (с установленным необходимым образом managed) и используйте атрибут ManyToManyField.through, чтобы отношение использовало вашу пользовательскую модель.

Для тестов, включающих модели с managed=False, вы должны убедиться, что в рамках настройки теста созданы правильные таблицы.

Если вы заинтересованы в изменении поведения уровня модели класса Python, вы можете использовать managed=False и создать копию существующей модели. Однако для этой ситуации есть лучший подход: Модели прокси.

Делает этот объект упорядоченным по отношению к заданному полю, обычно это 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 = ['-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)]

Дополнительные разрешения для входа в таблицу разрешений при создании этого объекта. Разрешения добавления, изменения, удаления и просмотра автоматически создаются для каждой модели. В этом примере указывается дополнительное разрешение, can_deliver_pizzas:

permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

Это список или кортеж из 2-х кортежей в формате (permission_code, human_readable_permission_name).

По умолчанию используется ('add', 'change', 'delete', 'view'). Вы можете настроить этот список, например, установив его в пустой список, если ваше приложение не требует каких-либо разрешений по умолчанию. Это должно быть указано в модели перед созданием модели с помощью migrate, чтобы предотвратить создание любых пропущенных разрешений.

Если proxy=True, модель, которая является подклассом другой модели, будет рассматриваться как proxy model.

Список функций базы данных, которые должно иметь текущее соединение, чтобы модель рассматривалась на этапе миграции. Например, если вы установите для этого списка значение ['gis_enabled'], модель будет синхронизироваться только в базах данных с поддержкой ГИС. Также полезно пропустить некоторые модели при тестировании с несколькими базами данных. Избегайте отношений между моделями, которые могут или не могут быть созданы, так как ORM не справляется с этим.

Имя поддерживаемого поставщика базы данных, к которому относится данная модель. Текущие имена встроенных поставщиков: sqlite, postgresql, mysql, oracle. Если этот атрибут не пустой и текущий поставщик соединений не соответствует ему, модель не будет синхронизирована.

Определяет, будет ли Django использовать алгоритм pre-1.6 django.db.models.Model.save(). Старый алгоритм использует SELECT, чтобы определить, существует ли существующая строка для обновления. Новый алгоритм пытается UPDATE напрямую. В некоторых редких случаях UPDATE существующей строки не видны Джанго. Примером является триггер PostgreSQL ON UPDATE, который возвращает NULL. В таких случаях новый алгоритм будет выполнять INSERT, даже если в базе данных существует строка.

Обычно нет необходимости устанавливать этот атрибут. Значением по умолчанию является False.

Смотрите django.db.models.Model.save() для получения дополнительной информации о старом и новом алгоритме сохранения.

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

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 = [['driver', 'restaurant']]

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

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

unique_together = ['driver', 'restaurant']

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

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

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

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

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

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

index_together = ["pub_date", "deadline"]

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

Если оно не задано, Django будет использовать поддельную версию имени класса: CamelCase становится camel case.

Имя во множественном числе для объекта:

verbose_name_plural = "stories"

Если не задано, Django будет использовать verbose_name + "s".

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

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