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

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

Параметры Meta

abstract

Options.abstract

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

app_label

Options.app_label

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

app_label = 'myapp'

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 автоматически экранирует название колонок и таблиц.

Use lowercase table names for MySQL

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

Table name quoting for 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 создаст необходимые таблицы в базе данных при выполнении команды syncdb и удалит их при выполнении 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>

Changing order_with_respect_to

order_with_respect_to добавляет дополнительное поле в таблицу базы данных с названием _order. Вам нужно будет добавить ее самостоятельно, если вы добавите order_with_respect_to в модель после syncdb.

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-х элементных кортежей в формате (код разрешения, название разрешения).

proxy

Options.proxy

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

select_on_save

Options.select_on_save
New in 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.

index_together

Options.index_together
New in Django 1.5.

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

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

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

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