Модели

Типы полей

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

• Тип столбца, который указывает базе данных, какие данные хранить (например, INTEGER, VARCHAR, TEXT).
• Стандартный HTML-виджет, используемый при отображении поля формы (например, <input type="text">, <select>).
• Минимальные требования к проверке данных, используемые в административном интерфейсе Django и автоматически создаваемых формах.

Django поставляется с десятками встроенных типов полей; полный список можно найти в справочнике по полям моделей. Если встроенные поля Django вам не подходят, вы можете легко написать собственные; см. Как создавать пользовательские поля моделей.

Параметры полей

Каждое поле принимает определённый набор аргументов, специфичных для этого поля (описанных в справочнике по полям моделей). Например, CharField (и его подклассам) требуется аргумент max_length, который задаёт размер поля базы данных VARCHAR для хранения данных.

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

null

Если задано значение True, Django будет хранить пустые значения в базе данных как NULL. По умолчанию — False.

blank

Если задано значение True, поле может быть пустым. По умолчанию — False.

Обратите внимание, что это отличается от null. Параметр null относится исключительно к базе данных, тогда как blank связан с проверкой данных. Если для поля задано blank=True, проверка формы позволит ввести пустое значение. Если для поля задано blank=False, поле будет обязательным.

choices

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

Список вариантов выглядит так:

YEAR_IN_SCHOOL_CHOICES = [
    ("FR", "Freshman"),
    ("SO", "Sophomore"),
    ("JR", "Junior"),
    ("SR", "Senior"),
    ("GR", "Graduate"),
]

Примечание

Новая миграция создаётся при каждом изменении порядка choices.

Первый элемент каждого кортежа — значение, которое будет сохранено в базе данных. Второй элемент отображается виджетом формы поля.

Для экземпляра модели отображаемое значение поля с параметром choices можно получить с помощью метода get_FOO_display(). Например:

from django.db import models


class Person(models.Model):
    SHIRT_SIZES = {
        "S": "Small",
        "M": "Medium",
        "L": "Large",
    }
    name = models.CharField(max_length=60)
    shirt_size = models.CharField(max_length=1, choices=SHIRT_SIZES)

>>> p = Person(name="Fred Flintstone", shirt_size="L")
>>> p.save()
>>> p.shirt_size
'L'
>>> p.get_shirt_size_display()
'Large'

Также можно использовать классы перечислений, чтобы кратко задавать choices:

from django.db import models


class Runner(models.Model):
    MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")
    name = models.CharField(max_length=60)
    medal = models.CharField(blank=True, choices=MedalType, max_length=10)

Дополнительные примеры доступны в справочнике по полям моделей.

default

Значение поля по умолчанию. Это может быть значение или вызываемый объект. Если это вызываемый объект, он будет вызываться при каждом создании нового объекта.

db_default

Значение поля по умолчанию, вычисляемое базой данных. Это может быть литеральное значение или функция базы данных.

Если заданы и db_default, и Field.default, при создании экземпляров в коде Python приоритет будет у default. db_default всё равно будет установлено на уровне базы данных и будет использоваться при вставке строк в обход ORM или при добавлении нового поля в миграции.

help_text

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

primary_key

Если задано значение True, это поле является первичным ключом модели.

Если ни для одного поля модели не задан параметр primary_key=True, Django автоматически добавит поле для хранения первичного ключа, поэтому вам не нужно устанавливать primary_key=True ни для одного из полей, если только вы не хотите изменить поведение первичного ключа по умолчанию. Подробнее см. в разделе Автоматические поля первичного ключа.

Поле первичного ключа доступно только для чтения. Если изменить значение первичного ключа существующего объекта и сохранить его, рядом со старым будет создан новый объект. Например:

from django.db import models


class Fruit(models.Model):
    name = models.CharField(max_length=100, primary_key=True)

>>> fruit = Fruit.objects.create(name="Apple")
>>> fruit.name = "Pear"
>>> fruit.save()
>>> Fruit.objects.values_list("name", flat=True)
<QuerySet ['Apple', 'Pear']>

unique

Если задано значение True, значение этого поля должно быть уникальным во всей таблице.

Повторим: это лишь краткие описания наиболее распространённых параметров полей. Полную информацию можно найти в справочнике по общим параметрам полей моделей.

Автоматические поля первичного ключа

По умолчанию Django добавляет каждой модели автоинкрементируемый первичный ключ с типом, указанным для приложения в параметре AppConfig.default_auto_field или глобально в настройке DEFAULT_AUTO_FIELD. Например:

id = models.BigAutoField(primary_key=True)

Чтобы задать пользовательский первичный ключ, укажите primary_key=True для одного из полей. Если Django обнаружит, что вы явно задали Field.primary_key, автоматический столбец id добавлен не будет.

В каждой модели ровно одно поле должно иметь параметр primary_key=True (заданный явно или добавленный автоматически).

Подробные имена полей

Для каждого типа поля, кроме ForeignKey, ManyToManyField и OneToOneField, можно указать необязательный первый позиционный аргумент — подробное имя. Если оно не задано, Django автоматически создаст его на основе имени атрибута поля, заменив символы подчёркивания пробелами.

В этом примере подробное имя — "person's first name":

first_name = models.CharField("person's first name", max_length=30)

В этом примере подробное имя — "first name":

first_name = models.CharField(max_length=30)

Для ForeignKey, ManyToManyField и OneToOneField первым аргументом должен быть класс модели, поэтому используйте именованный аргумент verbose_name:

poll = models.ForeignKey(
    Poll,
    on_delete=models.CASCADE,
    verbose_name="the related poll",
)
sites = models.ManyToManyField(Site, verbose_name="list of sites")
place = models.OneToOneField(
    Place,
    on_delete=models.CASCADE,
    verbose_name="related place",
)

Принято не писать первую букву verbose_name заглавной. Django автоматически сделает её заглавной там, где это необходимо.

Связи

Очевидно, сила реляционных баз данных заключается в возможности связывать таблицы друг с другом. Django позволяет задавать три наиболее распространённых типа связей в базах данных: «многие к одному», «многие ко многим» и «один к одному».

from django.db import models


class Manufacturer(models.Model):
    # ...
    pass


class Car(models.Model):
    manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)
    # ...

class Car(models.Model):
    company_that_makes_it = models.ForeignKey(
        Manufacturer,
        on_delete=models.CASCADE,
    )
    # ...

from django.db import models


class Topping(models.Model):
    # ...
    pass


class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)

from django.db import models


class Person(models.Model):
    name = models.CharField(max_length=128)

    def __str__(self):
        return self.name


class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Person, through="Membership")

    def __str__(self):
        return self.name


class Membership(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["person", "group"], name="unique_person_group"
            )
        ]

>>> ringo = Person.objects.create(name="Ringo Starr")
>>> paul = Person.objects.create(name="Paul McCartney")
>>> beatles = Group.objects.create(name="The Beatles")
>>> m1 = Membership(
...     person=ringo,
...     group=beatles,
...     date_joined=date(1962, 8, 16),
...     invite_reason="Needed a new drummer.",
... )
>>> m1.save()
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>]>
>>> ringo.group_set.all()
<QuerySet [<Group: The Beatles>]>
>>> m2 = Membership.objects.create(
...     person=paul,
...     group=beatles,
...     date_joined=date(1960, 8, 1),
...     invite_reason="Wanted to form a band.",
... )
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>]>

>>> beatles.members.add(john, through_defaults={"date_joined": date(1960, 8, 1)})
>>> beatles.members.create(
...     name="George Harrison", through_defaults={"date_joined": date(1960, 8, 1)}
... )
>>> beatles.members.set(
...     [john, paul, ringo, george], through_defaults={"date_joined": date(1960, 8, 1)}
... )

>>> Membership.objects.create(
...     person=ringo,
...     group=beatles,
...     date_joined=date(1968, 9, 4),
...     invite_reason="You've been gone for a month and we miss you.",
... )
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>, <Person: Ringo Starr>]>
>>> # This deletes both of the intermediate model instances for Ringo Starr
>>> beatles.members.remove(ringo)
>>> beatles.members.all()
<QuerySet [<Person: Paul McCartney>]>

>>> # Beatles have broken up
>>> beatles.members.clear()
>>> # Note that this deletes the intermediate model instances
>>> Membership.objects.all()
<QuerySet []>

# Find all the groups with a member whose name starts with 'Paul'
>>> Group.objects.filter(members__name__startswith="Paul")
<QuerySet [<Group: The Beatles>]>

# Find all the members of the Beatles that joined after 1 Jan 1961
>>> Person.objects.filter(
...     group__name="The Beatles", membership__date_joined__gt=date(1961, 1, 1)
... )
<QuerySet [<Person: Ringo Starr]>

>>> ringos_membership = Membership.objects.get(group=beatles, person=ringo)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'

>>> ringos_membership = ringo.membership_set.get(group=beatles)
>>> ringos_membership.date_joined
datetime.date(1962, 8, 16)
>>> ringos_membership.invite_reason
'Needed a new drummer.'

Модели в разных файлах

Связать модель с моделью из другого приложения вполне допустимо. Для этого импортируйте связанную модель в начале файла, где определена ваша модель. Затем используйте класс другой модели там, где это необходимо. Например:

from django.db import models
from geography.models import ZipCode


class Restaurant(models.Model):
    # ...
    zip_code = models.ForeignKey(
        ZipCode,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

Вместо этого можно использовать отложенную ссылку на связанную модель в виде строки формата "app_label.ModelName". В этом случае импортировать связанную модель не требуется. Например:

from django.db import models


class Restaurant(models.Model):
    # ...
    zip_code = models.ForeignKey(
        "geography.ZipCode",
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

Подробнее см. в разделе Отложенные связи.

Ограничения на имена полей

Django накладывает некоторые ограничения на имена полей модели:

1. Имя поля не может быть зарезервированным словом Python, так как это приведёт к синтаксической ошибке Python. Например:

   class Example(models.Model):
       pass = models.IntegerField() # 'pass' is a reserved word!
   

2. Имя поля не может содержать несколько символов подчёркивания подряд из-за особенностей синтаксиса поиска в запросах Django. Например:

   class Example(models.Model):
       foo__bar = models.IntegerField()  # 'foo__bar' has two underscores!
   

3. По аналогичным причинам имя поля не может заканчиваться символом подчёркивания.
4. Имя поля не может быть check, так как это переопределит метод Model.check() фреймворка проверок.

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

Зарезервированные слова SQL, такие как join, where или select, допускаются в качестве имён полей модели, поскольку Django экранирует все имена таблиц и столбцов базы данных в каждом SQL-запросе. При этом используется синтаксис кавычек конкретного движка базы данных.

Пользовательские типы полей

Если ни одно из существующих полей модели не подходит для ваших целей или вы хотите использовать некоторые менее распространённые типы столбцов базы данных, вы можете создать собственный класс поля. Полное описание создания собственных полей приведено в разделе Как создавать пользовательские поля модели.

Переопределение предопределённых методов модели

Есть и другой набор методов модели, которые инкапсулируют ряд операций с базой данных, поведение которых может потребоваться изменить. В частности, часто возникает необходимость изменить работу методов save() и delete().

Вы можете переопределить эти методы (и любые другие методы модели), чтобы изменить их поведение.

Классический пример переопределения встроенных методов — необходимость выполнять какое-либо действие при каждом сохранении объекта. Например (описание принимаемых параметров см. в документации к save()):

from django.db import models


class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, **kwargs):
        do_something()
        super().save(**kwargs)  # Call the "real" save() method.
        do_something_else()

Также можно запретить сохранение:

from django.db import models


class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def save(self, **kwargs):
        if self.name == "Yoko Ono's blog":
            return  # Yoko shall never have her own blog!
        else:
            super().save(**kwargs)  # Call the "real" save() method.

Важно не забыть вызвать метод суперкласса — то самое дело super().save(**kwargs) — чтобы объект по-прежнему сохранялся в базе данных. Если не вызвать метод суперкласса, поведение по умолчанию не будет выполняться и база данных не будет затронута.

Также важно передавать аргументы, которые можно передать методу модели, — за это отвечает часть **kwargs. Время от времени Django расширяет возможности встроенных методов модели, добавляя новые именованные аргументы. Если в определениях методов вы используете **kwargs, ваш код гарантированно будет автоматически поддерживать такие аргументы после их добавления.

Если вы хотите обновить значение поля в методе save(), возможно, потребуется также добавить это поле в именованный аргумент update_fields. Это гарантирует сохранение поля, когда указан update_fields. Например:

from django.db import models
from django.utils.text import slugify


class Blog(models.Model):
    name = models.CharField(max_length=100)
    slug = models.TextField()

    def save(self, **kwargs):
        self.slug = slugify(self.name)
        if (
            update_fields := kwargs.get("update_fields")
        ) is not None and "name" in update_fields:
            kwargs["update_fields"] = {"slug"}.union(update_fields)
        super().save(**kwargs)

Подробнее см. раздел Указание полей для сохранения.

Выполнение пользовательского SQL

Ещё один распространённый подход — написание пользовательских SQL-инструкций в методах модели и методах уровня модуля. Подробнее об использовании необработанного SQL см. в документации по использованию необработанного SQL.

Абстрактные базовые классы

Абстрактные базовые классы полезны, когда нужно добавить общую информацию в несколько других моделей. Создайте базовый класс и укажите abstract=True во внутреннем классе Meta. Эта модель не будет использоваться для создания таблицы в базе данных. Вместо этого при использовании её в качестве базового класса для других моделей её поля будут добавлены к полям дочернего класса.

Например:

from django.db import models


class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True


class Student(CommonInfo):
    home_group = models.CharField(max_length=5)

Модель Student будет иметь три поля: name, age и home_group. Модель CommonInfo нельзя использовать как обычную модель Django, поскольку это абстрактный базовый класс. Она не создаёт таблицу в базе данных и не имеет менеджера, а также не может быть непосредственно создана или сохранена.

Поля, унаследованные от абстрактных базовых классов, можно переопределить другим полем или значением либо удалить с помощью None.

Для многих задач такой тип наследования моделей подойдёт идеально. Он позволяет вынести общую информацию на уровень Python, при этом на уровне базы данных для каждой дочерней модели создаётся только одна таблица.

from django.db import models


class CommonInfo(models.Model):
    # ...
    class Meta:
        abstract = True
        ordering = ["name"]


class Student(CommonInfo):
    # ...
    class Meta(CommonInfo.Meta):
        db_table = "student_info"

from django.db import models


class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True
        ordering = ["name"]


class Unmanaged(models.Model):
    class Meta:
        abstract = True
        managed = False


class Student(CommonInfo, Unmanaged):
    home_group = models.CharField(max_length=5)

    class Meta(CommonInfo.Meta, Unmanaged.Meta):
        pass

from django.db import models


class Base(models.Model):
    m2m = models.ManyToManyField(
        OtherModel,
        related_name="%(app_label)s_%(class)s_related",
        related_query_name="%(app_label)s_%(class)ss",
    )

    class Meta:
        abstract = True


class ChildA(Base):
    pass


class ChildB(Base):
    pass

from common.models import Base


class ChildB(Base):
    pass

Наследование с несколькими таблицами

Второй поддерживаемый Django тип наследования моделей — когда каждая модель в иерархии является самостоятельной моделью. Каждая модель соответствует собственной таблице в базе данных, и её можно запрашивать и создавать отдельно. Связь наследования создаёт ссылки между дочерней моделью и каждым из её родителей (посредством автоматически создаваемого OneToOneField). Например:

from django.db import models


class Place(models.Model):
    name = models.CharField(max_length=50)
    address = models.CharField(max_length=80)


class Restaurant(Place):
    serves_hot_dogs = models.BooleanField(default=False)
    serves_pizza = models.BooleanField(default=False)

Все поля Place будут доступны и в Restaurant, хотя данные будут храниться в другой таблице базы данных. Поэтому возможны оба варианта:

>>> Place.objects.filter(name="Bob's Cafe")
>>> Restaurant.objects.filter(name="Bob's Cafe")

Если у вас есть объект Place, который также является Restaurant, перейти от объекта Place к объекту Restaurant можно с помощью имени модели в нижнем регистре:

>>> p = Place.objects.get(id=12)
# If p is a Restaurant object, this will give the child class:
>>> p.restaurant
<Restaurant: ...>

Однако если p в приведённом выше примере не являлся Restaurant (если он был создан непосредственно как объект Place или был родителем какого-либо другого класса), обращение к p.restaurant вызвало бы исключение Restaurant.DoesNotExist.

Автоматически создаваемое поле OneToOneField в Restaurant, связывающее его с Place, выглядит так:

place_ptr = models.OneToOneField(
    Place,
    on_delete=models.CASCADE,
    parent_link=True,
    primary_key=True,
)

Это поле можно переопределить, объявив собственное OneToOneField с параметром parent_link=True в Restaurant.

class ChildModel(ParentModel):
    # ...
    class Meta:
        # Remove parent's ordering effect
        ordering = []

class Supplier(Place):
    customers = models.ManyToManyField(Place)

Reverse query name for 'Supplier.customers' clashes with reverse query
name for 'Supplier.place_ptr'.

HINT: Add or change a related_name argument to the definition for
'Supplier.customers' or 'Supplier.place_ptr'.

Прокси-модели

При использовании наследования с несколькими таблицами для каждого подкласса модели создаётся новая таблица в базе данных. Обычно это желаемое поведение, поскольку подклассу нужно место для хранения дополнительных полей данных, которых нет в базовом классе. Однако иногда требуется изменить только поведение модели в Python — например, изменить менеджер по умолчанию или добавить новый метод.

Для этого и предназначено наследование прокси-моделей: оно создаёт прокси исходной модели. Можно создавать, удалять и обновлять экземпляры прокси-модели, и все данные будут сохраняться так, как если бы вы использовали исходную модель (не прокси). Разница в том, что в прокси можно менять такие параметры, как порядок сортировки модели по умолчанию или менеджер по умолчанию, не изменяя исходную модель.

Прокси-модели объявляются так же, как обычные модели. Чтобы сообщить Django, что модель является прокси-моделью, установите атрибут proxy класса Meta в значение True.

Например, предположим, что вы хотите добавить метод в модель Person. Это можно сделать так:

from django.db import models


class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)


class MyPerson(Person):
    class Meta:
        proxy = True

    def do_something(self):
        # ...
        pass

Класс MyPerson работает с той же таблицей базы данных, что и его родительский класс Person. В частности, любой новый экземпляр Person будет доступен и через MyPerson, и наоборот:

>>> p = Person.objects.create(first_name="foobar")
>>> MyPerson.objects.get(first_name="foobar")
<MyPerson: foobar>

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

class OrderedPerson(Person):
    class Meta:
        ordering = ["last_name"]
        proxy = True

Обычные запросы Person теперь не будут отсортированы, а запросы OrderedPerson будут сортироваться по last_name.

Прокси-модели наследуют атрибуты Meta так же, как обычные модели.

from django.db import models


class NewManager(models.Manager):
    # ...
    pass


class MyPerson(Person):
    objects = NewManager()

    class Meta:
        proxy = True

# Create an abstract class for the new manager.
class ExtraManagers(models.Model):
    secondary = NewManager()

    class Meta:
        abstract = True


class MyPerson(Person, ExtraManagers):
    class Meta:
        proxy = True

Множественное наследование

Как и при создании подклассов в Python, модель Django может наследоваться от нескольких родительских моделей. Помните, что действуют обычные правила разрешения имён Python. Будет использован первый базовый класс, в котором встречается конкретное имя (например, Meta). Например, если несколько родителей содержат класс Meta, будет использован только первый, а все остальные будут проигнорированы.

Как правило, наследование от нескольких родителей не требуется. Оно полезно главным образом для классов-«примесей»: они добавляют определённое поле или метод в каждый класс, который от них наследуется. Старайтесь делать иерархии наследования как можно проще и понятнее, чтобы не приходилось разбираться, откуда взялась та или иная информация.

Обратите внимание: наследование от нескольких моделей с общим первичным ключом id приведёт к ошибке. Чтобы правильно использовать множественное наследование, можно явно задать AutoField в базовых моделях:

class Article(models.Model):
    article_id = models.AutoField(primary_key=True)
    ...


class Book(models.Model):
    book_id = models.AutoField(primary_key=True)
    ...


class BookReview(Book, Article):
    pass

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

class Piece(models.Model):
    pass


class Article(Piece):
    article_piece = models.OneToOneField(
        Piece, on_delete=models.CASCADE, parent_link=True
    )
    ...


class Book(Piece):
    book_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)
    ...


class BookReview(Book, Article):
    pass

«Сокрытие» имён полей не допускается

При обычном наследовании классов Python дочерний класс может переопределять любой атрибут родительского класса. В Django это обычно не допускается для полей модели. Если неабстрактный базовый класс модели содержит поле с именем author, нельзя создать другое поле модели или определить атрибут с именем author ни в одном классе, наследующем этот базовый класс.

Это ограничение не распространяется на поля модели, унаследованные от абстрактной модели. Такие поля можно переопределить другим полем или значением либо удалить, присвоив field_name = None.

Переопределение полей родительской модели приводит к сложностям, например при инициализации новых экземпляров (когда нужно указать, какое поле инициализируется в Model.__init__) и при сериализации. Обычному наследованию классов Python не приходится решать такие задачи тем же способом, поэтому различия между наследованием моделей Django и наследованием классов Python не случайны.

Это ограничение относится только к атрибутам, являющимся экземплярами Field. При необходимости обычные атрибуты Python можно переопределять. Ограничение также касается только имени атрибута с точки зрения Python: если имя столбца базы данных задано вручную, при наследовании с несколькими таблицами в дочерней и родительской модели может встречаться одно и то же имя столбца (это столбцы в двух разных таблицах базы данных).

Если переопределить любое поле модели в любом классе-предке, Django вызовет исключение FieldError.

Обратите внимание: из-за особенностей разрешения полей при определении класса поля модели, унаследованные от нескольких абстрактных родительских моделей, разрешаются в строгом порядке поиска в глубину. Это отличается от стандартного порядка разрешения методов Python (MRO), который при ромбовидном наследовании определяется поиском в ширину. Это различие затрагивает только сложные иерархии моделей, которых (согласно приведённой выше рекомендации) следует избегать.