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 . Все остальные аспекты управления моделью обрабатываются как для обычной модели. Это включает :

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

  2. Если модель с 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

Вместо этого используйте 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

Вместо этого используйте опцию indexes .

Более indexes новый вариант предлагает больше возможностей, чем » index_together . В будущем возможно исключить использование index_toght.

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

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

Атрибуты Meta только для чтения

label

Options.label

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

label_lower

Options.label_lower

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

Copyright ©2021 All rights reserved