Meta
Шаблон опции ¶
В этом документе объясняются все параметры метаданных, которые могут быть назначены моделям в их Meta
внутреннем классе .
Meta
Доступные варианты ¶
abstract
¶
-
Options.
abstract
¶ Да , эта модель будет абстрактным базовым классом .
abstract = True
app_label
¶
-
Options.
app_label
¶ Если модель определена вне приложения в
INSTALLED_APPS
, она должна объявить, какому приложению она принадлежит:app_label = 'myapp'
Если вы хотите представить модель в формате
étiquette_app.nom_objet
илиétiquette_app.nom_modèle
, вы можете соответственно использоватьmodel._meta.label
илиmodel._meta.label_lower
.
base_manager_name
¶
-
Options.
base_manager_name
¶ _base_manager
Например, имя атрибута обработчика, которое будет использоваться для атрибута шаблона'objects'
.
db_table
¶
-
Options.
db_table
¶ Имя таблицы базы данных для использования в модели:
db_table = 'music_album'
Имена таблиц ¶
Чтобы сэкономить ваше время, Django автоматически извлекает имя таблицы базы данных из имени класса модели и приложения, в котором он находится. Имя таблицы базы данных модели создается путем добавления «метки» приложения модели (имени, используемого при заказе ) к имени класса модели в сочетании с подчеркиванием.manage.py startapp
Например, для приложения bibliotheque
(которое будет создано с помощью ) и шаблона, определенного с помощью , имя таблицы базы данных будет .manage.py startapp bibliotheque
class Livre
bibliotheque_livre
Чтобы переопределить имя таблицы базы данных, используйте атрибут db_table
class Meta
.
Если имя вашей таблицы базы данных является зарезервированным словом SQL или если оно содержит символы, недопустимые в именах переменных Python (особенно дефис), беспокоиться не о чем. , Django заключает имена столбцов и таблиц на заднем плане в кавычки.
Имена таблиц в нижнем регистре для MariaDB и MySQL
Настоятельно рекомендуется писать имена таблиц в нижнем регистре при их перегрузке db_table
, особенно при использовании механизма MySQL. См. Примечания для MySQL для получения более подробной информации.
Цитированные имена таблиц для Oracle
Чтобы соблюсти ограничение в 30 символов, которое Oracle помещает в имена таблиц, и следовать обычным соглашениям баз данных Oracle, Django может сокращать имена таблиц и переводить их в верхний регистр. Чтобы предотвратить эти преобразования, записывайте значения в кавычках в db_table
:
db_table = '"name_left_in_lowercase"'
Также можно использовать такие имена в кавычках с другими механизмами баз данных, поддерживаемыми Django; однако, в отличие от Oracle, кавычки не действуют. См. Подробности в Oracle Notes .
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
. Этот параметр определяет поля по умолчанию, которые будут использоваться в методах моделиlatest()
иearliest()
manager (Manager
).Пример:
# 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]
Порядок связанных объектов
Answer
объектаQuestion
можно определить, передав список первичных ключей объекта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)]
Предупреждение
Сортировка - нетривиальная операция. Каждое поле, добавленное в критерии сортировки, требует затрат на уровне базы данных. Каждый добавленный внешний ключ также неявно включает все поля сортировки по умолчанию.
Если запрос не имеет порядка сортировки, результаты возвращаются из базы данных в неопределенном порядке. Определенный порядок может быть гарантирован только в том случае, если порядок основан на одном или нескольких полях, которые однозначно идентифицируют каждый объект результата. Например, если поле nom
не уникально, сортировка по этому полю не гарантирует, что объекты с одинаковым именем всегда будут отображаться в одном и том же порядке.
permissions
¶
-
Options.
permissions
¶ Дополнительные разрешения для интеграции в таблицу разрешений при создании этого объекта. Разрешения на добавление, изменение, удаление и просмотр автоматически создаются для всех моделей. В этом примере добавляется дополнительное разрешение
can_deliver_pizzas
:permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]
Это список или кортеж двоичных кортежей в формате .
(code_permission, nom_verbeux_permission)
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_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"]
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».