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

Если модель определена вне приложения из INSTALLED_APPS, она должна указать к какому приложению она относится:

app_label = 'myapp'

Если вы хотите представить модель в формате app_label.object_name или app_label.model_name, вы можете использовать model._meta.label и model._meta.label_lower соответственно.

Имя атрибута менеджера, например 'objects', для использования в _base_manager модели.

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

db_table = 'music_album'

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

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

Название, которое будет использоваться для обратных связей к этой модели. По умолчанию <model_name>_set.

Эта опция также устанавливает related_query_name.

Т.к. название поля обратной связи должно быть уникальным, будьте осторожны, если собираетесь наследоваться от модели. Чтобы избежать коллизий в названиях, можно добавить '%(app_label)s' и '%(model_name)s', которые будут заменены соответственно на название приложения модели и название модели в нижнем регистре. Смотрите именование обратных связей для абстрактных моделей.

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

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

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

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

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

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

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

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

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

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'

When order_with_respect_to is set, two additional methods are provided to retrieve and to set the order of the related objects: get_RELATED_order() and set_RELATED_order(), where RELATED is the lowercased model name. For example, assuming that a Question object has multiple related Answer objects, the list returned contains the primary keys of the related Answer objects:

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

The order of a Question object’s related Answer objects can be set by passing in a list of Answer primary keys:

>>> question.set_answer_order([3, 1, 2])

The related objects also get two methods, get_next_in_order() and get_previous_in_order(), which can be used to access those objects in their proper order. Assuming the Answer objects are ordered by id:

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

Сортировка по умолчанию используемая при получении объектов:

ordering = ['-order_date']

Это кортеж или список строк. Каждая строка это название поля с необязательным префиксом «-», который указывает на нисходящую сортировку. Поля без «-» будут отсортированы по возрастанию. Используйте «?» для случайной сортировке.

Например, для сортировки по возрастанию по полю pub_date:

ordering = ['pub_date']

Нисходящая сортировка по полю pub_date:

ordering = ['-pub_date']

Для нисходящей сортировки по pub_date и восходящей по author, используйте:

ordering = ['-pub_date', 'author']

Вы также можете использовать выражения запроса. Чтобы упорядочить по возрастанию автора и сделать нулевые значения сортируемыми последними, используйте следующее:

from django.db.models import F

ordering = [F('author').asc(nulls_last=True)]

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

permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

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

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

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

Список функций базы данных, который необходимы для работы модели. Учитываются при миграции. Например, если указать ['gis_enabled'], таблица для модели будет создана только для базы данных, которая поддерживает GIS. Эта опция также полезна при тестировании на разных базах данных. Избегайте связей между моделями, которые не могут быть созданы в одной базе данных. ORM не умеет обрабатывать такие ситуации.

Список поддерживаемых баз данных. Текущий список: sqlite, postgresql, mysql, oracle. Если эта опция не пустая, и база данных не соответствует указанной, таблица для модели не будет создана при миграции.

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

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

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

Список индексов, которые вы хотите определить в модели:

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 = [['driver', 'restaurant']]

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

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

unique_together = ['driver', 'restaurant']

A ManyToManyField cannot be included in unique_together. (It’s not clear what that would even mean!) If you need to validate uniqueness related to a ManyToManyField, try using a signal or an explicit through model.

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

Sets of field names that, taken together, are indexed:

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

This list of fields will be indexed together (i.e. the appropriate CREATE INDEX statement will be issued.)

For convenience, index_together can be a single list when dealing with a single set of fields:

index_together = ["pub_date", "deadline"]

Список ограничений, которые вы хотите определить в модели:

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 = "pizza"

Если не указано, Django создаст из названия модели: CamelCase станет camel case.

Название модели в множественном числе:

verbose_name_plural = "stories"

Если не указано, Django создаст по правилу verbose_name + "s".

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

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