Параметры модели

Этот раздел описывает все возможные настройки модели которые вы можете определить через class Meta.

Параметры Meta

abstract

Options.abstract

При abstract = True, эта модель будет абстрактной моделью.

app_label

Options.app_label

Если модель находится не в стандартной локации (models.py или пакет models приложения), модель должна определять к какому приложению она принадлежит:

app_label = 'myapp'
Добавлено в Django 1.7:

app_label больше не обязательный параметр для моделей, которые находятся вне модуля models приложения.

db_table

Options.db_table

Название таблицы в базе данных для этой модели:

db_table = 'music_album'

Название таблицы

Экономя ваше время, Django автоматически создаст название таблицы из названия модели и приложения. Название таблицы состоит из названия приложения(“app label”) – название используемое для команды manage.py startapp – и названия модели, объединенные нижним подчеркиванием.

Например, есть приложение bookstore (созданное командой manage.py startapp bookstore), и модель class Book, название таблицы будет bookstore_book.

Для переопределения названия таблицы используйте атрибут db_table class Meta.

Если имя колонки это зарезервированное SQL слово, или содержит символы запрещенные в названиях переменной в Python – в частности, дефис – все нормально. Django автоматически экранирует название колонок и таблиц.

Используйте нижний регистр для названий таблиц в MySQL

Настоятельно рекомендуем использовать нижний регистр при переопределении названия таблицы через db_table, особенно при использовании MySQL. Подробности в примечания для MySQL.

Названия таблиц в кавычках для Oracle

Т.к в Oracle есть ограничение в 30 символов на название таблиц, и для соблюдения соглашений работы с Oracle, Django может ограничить название таблицы и преобразовать его в верхний регистр. Чтобы избежать этого, укажите название в кавычках в настройке db_table:

db_table = '"name_left_in_lowercase"'

Кавычки можно использовать для других типов базы данных, не только Oracle, однако, они не будут иметь никакого эффекта. Смотрите заметки о работе с Oracle.

db_tablespace

Options.db_tablespace

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

get_latest_by

Options.get_latest_by

Название сортируемого поля модели, обычно DateField, DateTimeField или IntegerField. Определяет поле по умолчанию, которое будет использовано методами latest() и earliest() Manager-а модели.

Например:

get_latest_by = "order_date"

Подробности в разделе о latest().

managed

Options.managed

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

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

  1. Автоматическое добавление первичного ключа, если он не был определен. Для ясности лучше определить в модели все поля таблицы, которую отображает модель с managed=False`.

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

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

Правильное создание таблиц при тестировании в тестовой базе данных для модели с managed=False ложится на ваши плечи.

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

order_with_respect_to

Options.order_with_respect_to

Объекты модели будут отсортированы относительно указанного поля. Почти всегда используется для связанных объектов. Например, модель Answer``(ответ) связана с моделью ``Question``(вопрос) через ``ForeignKey, вопрос содержит несколько ответов и порядок этих ответов имеет значение:

from django.db import models

class Question(models.Model):
    text = models.TextField()
    # ...

class Answer(models.Model):
    question = models.ForeignKey(Question)
    # ...

    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 передайте список первичных ключей в метод set_answer_order:

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

order_with_respect_to добавляет дополнительное поле в таблицу базы данных с названием _order. Не забудьте создать и применить миграцию, если вы добавите или поменяете 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']

Предупреждение

Сортировка не бесплатная операция. Каждое поле влияет на скорость выполнения запроса. Каждый внешний ключ добавит сортировку по умолчанию связанной модели.

permissions

Options.permissions

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

permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)

Это список 2-х элементных кортежей в формате (код разрешения, название разрешения).

default_permissions

Options.default_permissions
Добавлено в Django 1.7.

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

proxy

Options.proxy

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

select_on_save

Options.select_on_save
Добавлено в Django 1.6.

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

Обычно нет надобности менять эту настройку. По умолчанию равно False.

Различия работы старого и нового алгоритмов смотрите в описании метода django.db.models.Model.save().

unique_together

Options.unique_together

Множество полей, комбинация значений которых должна быть уникальна:

unique_together = (("driver", "restaurant"),)

Кортеж кортежей полей, которые должны быть вместе уникальны. Используется в интерфейсе администратора для проверки данных и на уровне базы данных (то есть соответствующее определение UNIQUE будет добавлено в CREATE TABLE запрос).

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

unique_together = ("driver", "restaurant")

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

Изменено в Django 1.7.

Будет вызвано исключение ValidationError в процессе проверки модели, если проверка ограничений(constraint) вернула ошибку с кодом unique_together.

index_together

Options.index_together

Множество полей, для которых создается один индекс:

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

Будет создан один индекс для группы полей (то есть будет выполнен необходимый CREATE INDEX.)

Изменено в Django 1.7.

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

index_together = ["pub_date", "deadline"]

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