Meta
Варианты модели ¶
В этом документе объясняются все возможные варианты метаданных, которые вы можете предоставить своей модели во внутреннем виде
.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 цитирует имена столбцов и таблиц за кулисами.
Используйте строчные имена таблиц для MariaDB и MySQL
Настоятельно рекомендуется использовать имена таблиц в нижнем регистре, когда вы переопределяете имя таблицы с помощью db_table
, особенно если вы используете серверную часть MySQL. См. Примечания к MySQL для получения более подробной информации.
Цитирование имен таблиц для Oracle
Чтобы соответствовать ограничению Oracle на 30 символов для имен таблиц и соответствовать обычным соглашениям для баз данных Oracle, Django может сокращать имена таблиц и переводить их в верхний регистр. Чтобы предотвратить такие преобразования, используйте имя в кавычках в качестве значения для db_table
:
db_table = '"name_left_in_lowercase"'
Такие имена в кавычках также можно использовать с другими поддерживаемыми базами данных Django; Однако, за исключением Oracle, кавычки не действуют. См. Примечания Oracle для получения более подробной информации.
db_tablespace
¶
-
Options.
db_tablespace
¶ Имя табличного пространства базы данных, которое будет использоваться для этой модели. По умолчанию это настройка проекта
DEFAULT_TABLESPACE
, если она установлена. Если серверная часть не поддерживает табличные пространства, этот параметр игнорируется.
default_manager_name
¶
-
Options.
default_manager_name
¶ Имя менеджера, используемого для модели
_default_manager
.
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
. Все остальные аспекты работы с моделью такие же, как обычно. Это включает в себяДобавление в модель автоматического поля первичного ключа, если вы его не объявляете. Чтобы избежать путаницы для более поздних программ чтения кода, рекомендуется указать все столбцы из таблицы базы данных, которую вы моделируете, при использовании неуправляемых моделей.
Если модель с
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>
order_with_respect_to
неявно устанавливает ordering
параметр
Внутренне order_with_respect_to
добавляет дополнительное поле / столбец базы данных с именем _order
и устанавливает параметр модели ordering
для этого поля. Следовательно, order_with_respect_to
и
ordering
не могут использоваться вместе, и порядок, добавленный с помощью,
order_with_respect_to
будет применяться всякий раз, когда вы получаете список объектов этой модели.
Изменение order_with_respect_to
Поскольку order_with_respect_to
добавляется новый столбец базы данных, обязательно выполните и примените соответствующие миграции, если вы добавляете или изменяете
order_with_respect_to
после первоначального migrate
.
ordering
¶
-
Options.
ordering
¶ Порядок по умолчанию для объекта, используемый при получении списков объектов:
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)]
Предупреждение
Заказ не является бесплатной операцией. Каждое поле, которое вы добавляете в заказ, требует затрат для вашей базы данных. Каждый добавляемый вами внешний ключ будет неявно включать все свои порядки по умолчанию.
Если для запроса не указан порядок, результаты возвращаются из базы данных в неопределенном порядке. Определенный порядок гарантируется только при упорядочивании по набору полей, которые однозначно идентифицируют каждый объект в результатах. Например, если name
поле не является уникальным, его упорядочение не гарантирует, что объекты с одинаковым именем всегда будут отображаться в одном и том же порядке.
permissions
¶
-
Options.
permissions
¶ Дополнительные разрешения для ввода в таблицу разрешений при создании этого объекта. Разрешения на добавление, изменение, удаление и просмотр автоматически создаются для каждой модели. В этом примере указывается дополнительное разрешение
can_deliver_pizzas
:permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]
Это список или кортеж из двух кортежей в формате .
(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']
, модель будет синхронизироваться только в базах данных с поддержкой ГИС. Также полезно пропустить некоторые модели при тестировании с несколькими базами данных. Избегайте отношений между моделями, которые могут или не могут быть созданы, поскольку 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
¶ Наборы имен полей, вместе взятые, должны быть уникальными:
unique_together = [['driver', 'restaurant']]
Это список списков, которые должны быть уникальными при рассмотрении вместе. Он используется в администраторе Django и применяется на уровне базы данных (т. Е. Соответствующие
UNIQUE
операторы включены в оператор).CREATE TABLE
Для удобства
unique_together
при работе с одним набором полей может быть единый список:unique_together = ['driver', 'restaurant']
А
ManyToManyField
не может быть включен в unique_toght. (Непонятно, что это вообще может значить!) Если вам нужно проверить уникальность, связанную с aManyToManyField
, попробуйте использовать сигнал или явнуюthrough
модель.ValidationError
Поднятый во время проверки модели , когда ограничение нарушается , имеетunique_together
код ошибки.
index_together
¶
-
Options.
index_together
¶ Наборы имен полей, которые, вместе взятые, индексируются:
index_together = [ ["pub_date", "deadline"], ]
Этот список полей будет проиндексирован вместе (т. Е. Будет выдано соответствующее заявление.)
CREATE INDEX
Для удобства
index_together
при работе с одним набором полей может быть единый список:index_together = ["pub_date", "deadline"]
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"
.