Этот раздел описывает все возможные настройки модели которые вы можете определить через class Meta.
При abstract = True, эта модель будет абстрактной моделью.
Если модель находится не в models.py (например, модели находятся в модулях пакета myapp.models), модель должна определять к какому приложению принадлежит модель:
app_label = 'myapp'
Название таблицы в базе данных для этой модели:
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.
Имя “tablespace” базы данных для этой модели. По-умолчанию используется настройка DEFAULT_TABLESPACE, если она определена. Если база данных не поддерживает “tablespace” для индексов, этот параметр будет проигнорирован.
Название поля DateField или DateTimeField модели. Определяет поле по-умолчанию, которое будет использовано методом latest Manager модели.
Например:
get_latest_by = "order_date"
Подробности в разделе о latest().
По-умолчанию True, означает что Django создаст необходимые таблицы в базе данных при выполнении команды syncdb и удалит их при выполнении reset. То есть Django управляет таблицами.
При False, таблицы модели не будет создаваться или удаляться. Это полезно, если модель отображает существующую таблицу или “VIEW” в базе данных, которая была создана другим способом. Это единственная разница при managed=False. Все остальные этапы работы с моделью не изменяются. Они включают
Автоматическое добавление первичного ключа, если он не был определен. Для ясности лучше определить в модели все поля таблицы, которую отображает модель с managed=False`.
Если модель с managed=False содержит ManyToManyField на другую неуправляемую модель, промежуточная таблица для хранения связи многое-ко-многим не будет создана. Однако, промежуточная таблица между управляемой и не управляемой моделью будет создана.
Если вы хотите переопределить такое поведение по-умолчанию, создайте модель для промежуточной таблицы (с необходимым managed) и укажите использование этой модели через параметр ManyToManyField.through.
Правильное создание таблиц при тестировании в тестовой базе данных для модели с managed=False ложится на ваши плечи.
Если вы хотите переопределить поведение модели на уровне Python, вы можете использовать managed=False и создать копию существующей модели. Однако, есть лучшее решение для такой ситуации: Proxy-модели.
Объекты модели будут отсортированы относительно указанного поля. Почти всегда используется для связанных объектов. Например, модель Answer``(ответ) связана с моделью ``Question``(вопрос) через ``ForeignKey, вопрос содержит несколько ответов и порядок этих ответов имеет значение:
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 = ['-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-модель.
Множество полей, комбинация значений которых должна быть уникальна:
unique_together = (("driver", "restaurant"),)
Используется в интерфейсе администратора для проверки данных и на уровне базы данных (то есть соответствующее определение UNIQUE будет добавлено в CREATE TABLE запрос).
Для удобства unique_together может быть одноуровневым списком, если определяется один набор уникальных полей:
unique_together = ("driver", "restaurant")
ManyToManyField не должен быть включен в unique_together. (Не понятно что подразумевается.) Если вам необходимо проверить уникальность связанных через ManyToManyField объектов, попробуйте использовать сигналы или подходящую through model.
Читабельное название модели, в единственном числе:
verbose_name = "pizza"
Если не указано, Django создаст из названия модели: CamelCase станет camel case.
Название модели в множественном числе:
verbose_name_plural = "stories"
Если не указано, Django создаст по правилу verbose_name + "s".
Aug 21, 2013