Этот раздел описывает все возможные настройки модели которые вы можете определить через class Meta.
При abstract = True, эта модель будет абстрактной моделью.
Если модель находится не в стандартной локации (models.py или пакет models приложения), модель должна определять к какому приложению она принадлежит:
app_label = 'myapp'
app_label больше не обязательный параметр для моделей, которые находятся вне модуля models приложения.
Название таблицы в базе данных для этой модели:
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.
Имя “tablespace” базы данных для этой модели. По умолчанию используется настройка DEFAULT_TABLESPACE, если она определена. Если база данных не поддерживает “tablespace” для индексов, этот параметр будет проигнорирован.
Название сортируемого поля модели, обычно DateField, DateTimeField или IntegerField. Определяет поле по умолчанию, которое будет использовано методами latest() и earliest() Manager-а модели.
Например:
get_latest_by = "order_date"
Подробности в разделе о latest().
По умолчанию True, означает что Django создаст необходимые таблицы в базе данных при выполнении команды migrate и удалит их при выполнении flush. То есть Django управляет таблицами.
При False, таблицы модели не будет создаваться или удаляться. Это полезно, если модель отображает существующую таблицу или “VIEW” в базе данных, которая была создана другим способом. Это единственная разница при managed=False. Все остальные этапы работы с моделью не изменяются. Они включают
Автоматическое добавление первичного ключа, если он не был определен. Для ясности лучше определить в модели все поля таблицы, которую отображает модель с managed=False`.
Если модель с managed=False содержит ManyToManyField на другую неуправляемую модель, промежуточная таблица для хранения связи многое-ко-многим не будет создана. Однако, промежуточная таблица между управляемой и не управляемой моделью будет создана.
Если вы хотите переопределить такое поведение по умолчанию, создайте модель для промежуточной таблицы (с необходимым managed) и укажите использование этой модели через параметр ManyToManyField.through.
Правильное создание таблиц при тестировании в тестовой базе данных для модели с managed=False ложится на ваши плечи.
Если вы хотите переопределить поведение модели на уровне Python, вы можете использовать managed=False и создать копию существующей модели. Однако, есть лучшее решение для такой ситуации: Proxy-модели.
Объекты модели будут отсортированы относительно указанного поля. Почти всегда используется для связанных объектов. Например, модель 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 = ['-order_date']
Это кортеж или список строк. Каждая строка это название поля с необязательным префиксом “-”, который указывает на нисходящую сортировку. Поля без “-” будут отсортированы по возрастанию. Используйте ”?” для случайной сортировке.
Например, для сортировки по возрастанию по полю pub_date:
ordering = ['pub_date']
Нисходящая сортировка по полю pub_date:
ordering = ['-pub_date']
Для нисходящей сортировки по pub_date и восходящей по author, используйте:
ordering = ['-pub_date', 'author']
Предупреждение
Сортировка не бесплатная операция. Каждое поле влияет на скорость выполнения запроса. Каждый внешний ключ добавит сортировку по умолчанию связанной модели.
Дополнительные разрешения(permissions) будут добавлены в таблицу разрешений при создании модели. Разрешения на добавление, удаление и изменение автоматически создаются для каждой модели. Этот пример добавляет разрешение can_deliver_pizzas:
permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
Это список 2-х элементных кортежей в формате (код разрешения, название разрешения).
При proxy = True, модель унаследованная от другой модели будет создана как proxy-модель.
Указывает использовать ли старый(до 1.6) алгоритм работы django.db.models.Model.save(). Старый алгоритм использовал SELECT для определения существует ли запись для обновления. Новый алгоритм сразу пробует обновить запись через UPDATE. В некоторых редких случаях UPDATE существующей записи не виден для Django. Например, в PostgreSQL срабатывание ON UPDATE возвращает NULL. В таких случаях новый алгоритм в конце концов попытается выполнить INSERT, даже если запись существует в базе данных.
Обычно нет надобности менять эту настройку. По умолчанию равно False.
Различия работы старого и нового алгоритмов смотрите в описании метода django.db.models.Model.save().
Множество полей, комбинация значений которых должна быть уникальна:
unique_together = (("driver", "restaurant"),)
Кортеж кортежей полей, которые должны быть вместе уникальны. Используется в интерфейсе администратора для проверки данных и на уровне базы данных (то есть соответствующее определение UNIQUE будет добавлено в CREATE TABLE запрос).
Для удобства unique_together может быть одноуровневым списком, если определяется один набор уникальных полей:
unique_together = ("driver", "restaurant")
ManyToManyField не должен быть включен в unique_together. (Не понятно что подразумевается.) Если вам необходимо проверить уникальность связанных через ManyToManyField объектов, попробуйте использовать сигналы или подходящую through model.
Будет вызвано исключение ValidationError в процессе проверки модели, если проверка ограничений(constraint) вернула ошибку с кодом unique_together.
Множество полей, для которых создается один индекс:
index_together = [
["pub_date", "deadline"],
]
Будет создан один индекс для группы полей (то есть будет выполнен необходимый CREATE INDEX.)
Для удобства index_together может быть одноуровневым списком, если определяется один набор полей:
index_together = ["pub_date", "deadline"]
Читабельное название модели, в единственном числе:
verbose_name = "pizza"
Если не указано, Django создаст из названия модели: CamelCase станет camel case.
Название модели в множественном числе:
verbose_name_plural = "stories"
Если не указано, Django создаст по правилу verbose_name + "s".
Jun 02, 2016