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

from django.db.models import F

ordering = [F('author').asc(nulls_last=True)]

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

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

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

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

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

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

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

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

Обычно этот атрибут устанавливать не нужно. По умолчанию это 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_toght. (Непонятно, что это вообще может значить!) Если вам нужно проверить уникальность, связанную с a ManyToManyField, попробуйте использовать сигнал или явную throughмодель.

ValidationErrorПоднятый во время проверки модели , когда ограничение нарушается , имеет unique_togetherкод ошибки.

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

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

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

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

index_together = ["pub_date", "deadline"]

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

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