Глубокое владение моделью Django.

Введение в ORM

ORM, а именно объектно-реляционное сопоставление (Object-Relational Mapping), его роль заключается в том, чтобы сделать сопоставление между реляционными базами данных и объектами бизнес-объектов, ORM обеспечивает абстракцию высокого уровня для реляционных баз данных, это позволяет разработчикам не писать SQL, только создавать, читать, обновлять и удалять данные в базе данных без написания кода. Разработчики могут использовать знакомый им язык программирования для работы с базой данных без написания операторов SQL или хранимых процедур.

Основными задачами ОРМ являются:

• Создание структуры таблицы на основе типа объекта
• Преобразование операций над объектами и списками в операторы SQL
• Преобразование результата запроса sql в объект, список

Преимущества ОРМ:

• Скрывая детали доступа к данным, ORM обеспечивает сопоставление с базой данных без прямого кодирования SQL и может получать данные из базы данных как объект операции.
• Повышайте эффективность разработки, практически все фреймворки ORM предоставляют функцию построения структуры реляционной базы данных через объектную модель.
• Реализовано разделение модели данных и базы данных, то есть дизайн модели данных не должен зависеть от конкретной базы данных, а базу данных можно легко заменить посредством простой настройки.

Недостатки ОРМ:

• Будет определенная потеря производительности, автоматизация означает сопоставление и управление ассоциациями за счет производительности. Различные фреймворки ORM теперь пытаются использовать различные методы, чтобы облегчить это (LazyLoad, Cache).
• Этого недостаточно для сложных запросов, таких как вычисляемый столбец, случай, группа, наличие, порядок, существует и т. д.
• Он должен потреблять больше памяти.Использование ORM извлечет все данные объекта в объект памяти, а затем отфильтрует и обработает их, что может привести к проблемам с производительностью.
• Переносит сложность с базы данных на код приложения, увеличивая общий размер кода Python, не разделяя код между хранимыми процедурами приложения и базы данных.

Распространенные ORM Python:

• Django ORM: Он поставляется с инфраструктурой Django и подходит для операций с базами данных простой или средней сложности. ORM основан на сложных операциях запроса, преобразованных в операторы SQL, которые более громоздки, чем операторы, написанные непосредственно с помощью SQL или сгенерированные с помощью SQLAlchemy.
• SQLAlchemy: широко известный Python ORM. По сравнению с Django ORM, он упрощает написание сложных запросов к базе данных.
• Peewee: «проще, меньше и легче взломать», чем SQLAlchemy. Peewee для SQLAlchemy — это то же самое, что SQLite для PostgreSQL. ORM не обязательно должен подходить для всех случаев использования, чтобы считаться полезным.

Django ORM против SQLAlchemy

Двумя наиболее распространенными реализациями ORM являются ActiveRecord и DataMapper, Прежде всего, характеристики этих двух режимов сохранения следующие:

• Active Record (режим активной записи) представляет собой отношение 1:1 между полями объекта модели предметной области и полями таблицы данных, то есть поле модели соответствует полю таблицы данных; затем объект модели предоставляет метод save() для сохранения модели. объект Persist на уровень хранения; модель знает об уровне данных, то есть в сочетании со слоем сохранения данных.
• Data Mapper (режим отображения данных) полностью слабо связывает объекты модели предметной области и таблицы данных.Объекты предметной области отвечают только за обработку бизнес-логики и вообще не знают слой данных, то есть они отвязаны от слоя данных;менеджер сущностей используется для сохранения объекта модели на уровне хранения; поля объекта модели могут иметь любое имя, если оно соответствует бизнес-модели, и могут быть сопоставлены с различными полями таблицы данных уровня данных.

Django ORMПримите реализацию Active Record — вы можете увидеть эту реализацию в большинстве ORM. По сути, также можно сказать, что каждая строка в базе данных напрямую сопоставляется с объектом в коде и наоборот. Фреймворкам ORM (таким как Django) не нужно предварительно определять схемы для использования атрибутов в коде, просто используйте их, потому что фреймворк может «понимать» структуру, глядя на схему базы данных. Кроме того, также можно просто сохранить запись в базе данных, поскольку она также сопоставляется с определенной строкой в ​​таблице.

SQLAlchemyРеализовано с отображением данных. При такой реализации возникает разрыв между структурой базы данных и структурой объекта (они не 1:1, как в реализации Active Record). В большинстве случаев для поддержки взаимодействия с базой данных (например, для сохранения объектов) необходимо использовать дополнительный уровень сохраняемости. Таким образом, при использовании Active Record нельзя просто вызвать метод save(), но, с другой стороны, коду не нужно знать работу всей реляционной структуры в базе данных, потому что нет прямой связи между код и база данных.

Очевидно, что Active Record относительно прост, но недостаточно гибок, а Data Mapper очень гибок, но добавлен менеджер сущностей, что увеличивает сложность. Если ваше приложение в основном представляет собой программы CRUD (создание, чтение, обновление, удаление) без использования сложных и сложных правил между различными объектами данных, вам следует использовать реализацию Active Record (Django). Если существует много «бизнес-правил» и ограничений, лучше использовать модель сопоставления данных, поскольку она не привязывает и не требует строгого соблюдения активных записей.

• Используйте сложные запросыВ некоторых случаях Django и SQLAlchemy можно использовать вместе. Основным вариантом использования в реальном мире является Django для всех обычных операций CRUD и SQLAlchemy для более сложных запросов, обычно запросов только для чтения.
• Первичный ключ генерируется автоматическиЕще одно различие между двумя фреймворками заключается в том, что Django может автоматически создавать первичные ключи для таблиц, чего не может SQLAlchemy. Первичные ключи должны создаваться вручную для каждой таблицы.
• автоматическая фиксацияПо умолчанию Django фиксирует автоматически, а SQLAlchemy — нет. Autocommit влияет на то, как используется фреймворк (транзакции, откаты и т. д.).
• поддерживаемые базы данныхВсе они доступны для MySQL, PostgreSQL, Oracle и SQLite. Если вы используете MSSQL, вам следует использовать SQLAlchemy, так как он полностью поддерживает MSSQL, и вы также можете найти дополнительную информацию и документацию по этому вопросу.
• кривая обученияДжанго проще в освоении. Поскольку он обычно используется для случаев использования, которые не являются особенно сложными.
• размер сообществаSQLAlchemy имеет самое большое сообщество среди фреймворков Python ORM. Если для вас важно сообщество, вам следует выбрать SQLAlchemy.
• представлениеТо, как вы используете функции платформы, может оказать огромное влияние на общую производительность уровня данных в вашем приложении. Так что не выбирайте фреймворк по производительности, а научитесь использовать фреймворк с умом.

Драйвер модели Django уделяет очень мало внимания деталям реализации на уровне базы данных, а процесс определения моделей разработчиками очень близок к декларативному, а не к процедурному.Для новых проектов это может быть причиной того, что модель Django более привлекательна, чем SQLAlchemy. . Традиционный способ использования SQLAlchemy заключается в том, чтобы не вторгаться в модель, определить структуру таблицы и правила отображения в отдельном месте, а затем использовать драйвер SQLAlchemy для внедрения в класс модели.Этот метод может полностью избежать связи между моделью и базы данных, но определение громоздкое и требует от разработчиков полного понимания механизма, метаданных, таблицы, столбца, преобразователя и т.п. концепция. Теперь SQLAlchemy предоставляет декларативный способ, который очень похож на модель Django, но все же имеет определенное расстояние от декларативной модели. По сравнению с декларативной моделью Django и SQLAlchemy, модель Django более лаконична. Например, для ассоциаций классов, если Django напрямую объявляет внешние ключи, он будет автоматически генерировать объекты ассоциации, в то время как SQLAlcyhemy необходимо определить внешние ключи, объекты отношений, а если внешних ключей несколько, вам нужно указать правила соединения самостоятельно.

Базы данных с поддержкой Django

Механизмы баз данных, поставляемые с Django:

• 'django.db.backends.postgresql'
• 'django.db.backends.mysql'
• 'django.db.backends.sqlite3'
• 'django.db.backends.oracle'

Дополнительные поддерживаемые сторонние базы данных:

• SAP SQL Anywhere
• IBM DB2
• Microsoft SQL Server
• Жар-птица
• ODBC
• ADSDB

Ссылка на ссылку:

• docs.Django project.com/en/2.0/hotwind/…
• docs.Django project.com/en/2.0/hotwind/…
• docs.Django project.com/en/2.0/topi…

Определение класса модели модели Django

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

Базовая структура определения модели выглядит следующим образом:

from django.db import models
 
class ModelName(models.Model):
    field1 = models.XXField(...)
    field2 = models.XXField(...)
    ...
    class Meta:
        db_table = ...
        other_metas = ...

• Все модели Django наследуются от класса db.models.Model.
• Атрибуты класса определяют поля модели, поля модели должны быть определенного типа XXField
• Подкласс Meta в классе определяет метаданные модели, такие как имя таблицы базы данных, порядок базы данных по умолчанию и т. д.

Имена мета-атрибутов предопределены Django.Обычно используемые мета-атрибуты:

• Аннотация: правда или ложь, указывая, является ли этот класс абстрактным
• App_Label: определяет приложение, к которому относится этот класс, например app_label = 'myApp'
• base_manager_name: имя менеджера _base_manager для пользовательской модели. Диспетчер моделей — это место, где находится API Django для моделей.
• db_table: имя сопоставленной таблицы базы данных, если оно не указано, имя таблицы базы данных будет автоматически использоваться в формате «имя приложения_имя модели».
• db_tablespace: имя сопоставленного табличного пространства, которое полезно только в некоторых базах данных с концепцией табличного пространства (например, Oracle), в противном случае оно будет проигнорировано.
• default_manager_name: имя менеджера, используемого _default_manager модели.
• default_related_name: определяет ссылочное имя обратной связи этой модели, которое по умолчанию совпадает с именем модели. Это имя будет использоваться по умолчанию для связи связанного объекта с текущим объектом. По умолчанию _set
• get_latest_by: определите, по какому значению поля следует сортировать, чтобы получить начальную или конечную запись модели. Этот атрибут обычно реализует поле модели даты или целого числа.
• управляемый: True или False, определяет, управляет ли инструмент командной строки Django py этой моделью. По умолчанию Истина. Если установлено значение False, запуск python manage migrate не будет создавать таблицы базы данных для этой модели в базе данных.
• order_with_respect_to: определяет, что эта модель может быть отсортирована в соответствии с отношением, на которое ссылается внешний ключ.
• порядок: поле сортировки по умолчанию для этой записи модели, вы можете установить несколько полей, по умолчанию используется восходящий порядок, если вы сортируете в порядке убывания, добавьте «знак минус» перед именем поля
• разрешения: Установите дополнительные разрешения в таблице разрешений при создании объектов. Это кортеж или список, содержащий два кортежа в формате (permission_code, human_readable_permission_name).
• default_permissions: права доступа к операции модели, по умолчанию ('добавить', 'изменить', 'удалить')
• прокси: True или False, независимо от того, являются ли эта модель и все подмодели, унаследованные от этой модели, прокси-моделями.
• required_db_features: определяет функции, которые должна иметь базовая база данных. Например, required_db_features=['gis_enabled'], создавайте эту модель данных только в той базе данных, которая удовлетворяет gis_enabled.
• required_db_vendor: определяет тип базовой базы данных, такой как SQLite, PostgreSQL, MySQL, Oracle. Если это свойство определено, модель может поддерживаться только в базе данных, в которой она объявлена.
• select_on_save: этот параметр определяет, использует ли Django алгоритм django.db.models.Model.save() до версии 6. Старые алгоритмы использовали SELECT, чтобы определить, есть ли строки, которые необходимо обновить. И более новые алгоритмы пытаются использовать UPDATE напрямую. В некоторых редких случаях операция UPDATE для существующей строки не видна для Django. Например, триггер PostgreSQL ON UPDATE вернет NULL. В этом случае новый алгоритм в конце выполнит операцию INSERT, даже если строка уже существует в базе данных. Обычно это свойство не нужно задавать. По умолчанию имеет значение Ложь.
• indexes: Список индексов для определения в модели.
• unique_together: установить совместный уникальный индекс unique_together = (("водитель", "ресторан"),)
• index_together: установить совместный индекс index_together = [["pub_date", "deadline"],]
• verbose_name: задает имя объекта в единственном числе, которое легко понять и выразить. Если этот элемент не установлен, Django разделит имя класса как имя файла readme, например, CamelCase станет верблюжьим регистром,
• verbose_name_plural: Указывает простое для понимания и выразительное имя объекта во множественном числе. Если это не установлено, Django будет использовать verbose_name + «s».

Мета-свойство только для чтения:

• метка: представление объекта, возвращает имя_объекта, например, «опросы.Вопрос».
• label_lower: представление модели, возвращает имя_модели, например, 'polls.question'.

Ссылка на ссылку:docs.Django project.com/en/2.0/hotwind/…

Общие типы полей моделей Django

Все типы полей должны наследоваться от django.db.models.Field Разработчики могут определить свои собственные типы полей, которые наследуются от этого класса, или они могут использовать ряд предопределенных подклассов Field из Django.

Предопределенные подклассы Django

• AutoField
• BigAutoField
• SmallIntegerField
• PositiveSmallIntegerField
• IntegerField
• PositiveIntegerField
• BigIntegerField
• FloatField
• DecimalField: передать параметр max_digits, должны быть переданы decimal_places.
• DateField
• TimeField
• DateTimeField
• DurationField: хранит периоды времени, созданные с использованием типа timedelta Python.
• BooleanField
• NullBooleanField: аналогично BooleanField, но с большим количеством параметров, чем None.
• CharField
• TextField
• SlugField: поле ввода, которое может содержать только буквы, цифры, знаки подчеркивания и дефисы, обычно используемые в URL-адресах.
• URLField
• EmailField
• GenericIPAddressField
• UUIDField
• BinaryField: поле двоичных данных, которому можно присвоить значение только через байты.
• FilePathField
• FileField: Поле загрузки файла, при определении этого поля должен быть передан параметр upload_to, который является путем файловой системы сервера для сохранения загруженного файла.
• ImageField: аналогично FileField и проверяет, является ли загруженное изображение допустимым изображением. Есть два необязательных параметра height_field и width_field.Если эти два параметра указаны, изображение будет сохранено в соответствии с предоставленными шириной и высотой. Для этого поля требуется, чтобы была установлена ​​библиотека Python Imaging.

Справочный адрес:docs.Django project.com/en/2.0/hotwind/…

Общие параметры полей моделей Django

• null: определяет, может ли поле базы данных иметь значение null, по умолчанию — False.
• пусто: определяет, может ли поле быть пустым, используется для проверки формы, чтобы определить, нельзя ли вводить данные, по умолчанию — False.
• Выбор: Дополнительное значение определенные значения, поле представляет собой двумерный элемент кортежа, первое значение - это фактическое значение каждого элемента хранения, второе значение - это значение, отображаемое при выборе HTML.
• Db_column: база данных, используемая для представления этого поля. Если вы не указаны, Django будет использовать имя поля в качестве имени поля.
• db_index: если True, для этого поля будет создан индекс.
• db_tablespace: если у поля есть индекс, имя табличного пространства базы данных будет использоваться в качестве имени индекса поля. Если DEFAULT_INDEX_TABLESPACE установлен, значение по умолчанию определяется DEFAULT_INDEX_TABLESPACE, если не установлено, указывается db_tablespace, если фоновая база данных не поддерживает табличное пространство или индекс, этот параметр игнорируется.
• по умолчанию: установить значение по умолчанию
• редактируемый: если установлено значение False, это поле не будет отображаться в администраторе или других, они также пропустят проверку модели, по умолчанию установлено значение True
• error_messages: Параметр error_messages позволяет переопределить выдаваемые по умолчанию сообщения об ошибках. Определите сообщение об ошибке, которое вы хотите переопределить, указав ключ.
• help_text: строка справки для элементов управления ввода страницы HTML
• primary_key: определяет, является ли поле первичным ключом, True или False.
• уникальный: это уникальное ограничение, определенное для поля
• unique_for_date
• unique_for_month
• unique_for_year
• verbose_name: более читаемое имя поля. Если пользователь не укажет избыточное поле имени, Django автоматически преобразует подчеркивание в имени атрибута поля в пробел и использует его для создания избыточного имени. может относиться кVerbose field names.
• валидаторы: список валидаторов, которые будут запущены для этого поля. Для получения дополнительной информации см.Документация для валидаторов.
• Безымянный параметр: задайте удобное для человека имя поля на HTML-странице.

Ссылка на ссылку:docs.Django project.com/en/2.0/hotwind/…

Пользовательские поля для моделей Django

Django официально предоставляет много Field, но иногда он все еще не может удовлетворить наши потребности, но Django предоставляет способ настроить Field. Поскольку он широко не используется, мы не будем здесь его подробно описывать.

Образец кода:Джанго snippets.org/snippets/28…

Ссылка на ссылку:docs.Django project.com/en/2.0/how t…

Настройки отношений модели Django

Моделирование данных и развитие бизнеса с использованием отношений между таблицами данных являются основными функциями реляционных баз данных. Три реляционные модели моделей Django (1:1, 1:N, M:N) имеют сильную поддержку.

отношение один к одному

В языке SQL отношение «один к одному» устанавливается с одним и тем же первичным ключом между двумя таблицами. Поле OneToOneField может быть определено в любой модели на уровне модели Django.

from django.db import models
 
class Account(models.Model):
    user_name = models.CharField(max_length=80)
    password = models.CharField(max_length=255)
    reg_date = models.DateField()
 
class Contact(models.Model):
    account = models.OneToOneField(
        Account,
        on_delete=models.CASCADE,
        primary_key=True
    )
    zip_code = models.CharField(max_length=10)
    address = models.CharField(max_length=80)
mobile = models.CharField(max_length=20)

Сгенерированный SQL:

BEGIN;
--
-- Create model Account
--
CREATE TABLE "app_account" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "user_name" varchar(80) NOT NULL, "password" varchar(255) NOT NULL, "reg_date" date NOT NULL);
--
-- Create model Contact
--
CREATE TABLE "app_contact" ("account_id" integer NOT NULL PRIMARY KEY REFERENCES "app_account" ("id") DEFERRABLE INITIALLY DEFERRED, "zip_code" varchar(10) NOT NULL, "address" varchar(80) NOT NULL, "mobile" varchar(20) NOT NULL);
COMMIT;

Вы можете видеть из приведенного выше кода:

• Два отношения модели определяются полем «Учетная запись» в модели «Контакт».
• Параметр OneToOneField определяется как: class OneToOneField(to, on_delete, parent_link=False, **options)
  • Первый параметр — это связанное имя класса.
  • Значение второго on_delete определяется db.models.deletion, а именно:
    • CASCADE: имитируйте ограничение ON DELETE CASCADE на языке SQL и одновременно удаляйте объекты модели с внешними ключами (операция по умолчанию и наиболее часто используемая).
    • DO_NOTHING: ничего не делать
    • ЗАЩИТА: Предотвратите операцию удаления, когда операция удаления будет выполнена, будет выдано исключение ProtectedError.
    • SET: установите значение, переданное в SET(), или возвращаемое значение функции обратного вызова.
    • SET_DEFAULT: установите для поля внешнего ключа значение по умолчанию. Его можно использовать только в том случае, если для поля установлен параметр по умолчанию.
    • SET_NULL: установите для поля внешнего ключа значение null, это значение можно использовать только в том случае, если для поля установлено значение null = True.

отношение один ко многим

В языке SQL отношение 1:N создается путем установки ссылки внешнего ключа в «расписании» на «основную таблицу». На уровне модели Django внешние ключи могут быть определены с использованием полей типа models.ForeignKey.

В приведенном выше случае, если между учетной записью и контактом существует отношение «один ко многим», просто измените код следующим образом:

from django.db import models
 
class Account(models.Model):
    user_name = models.CharField(max_length=80)
    password = models.CharField(max_length=255)
    reg_date = models.DateField()
 
class Contact(models.Model):
    account = models.ForeignKey(
        Account,
        on_delete=models.CASCADE
    )
    zip_code = models.CharField(max_length=10)
    address = models.CharField(max_length=80)
mobile = models.CharField(max_length=20)

Сгенерированный оператор SQL выглядит следующим образом:

BEGIN;
--
-- Create model Account
--
CREATE TABLE "app_account" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "user_name" varchar(80) NOT NULL, "password" varchar(255) NOT NULL, "reg_date" date NOT NULL);
--
-- Create model Contact
--
CREATE TABLE "app_contact" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "zip_code" varchar(10) NOT NULL, "address" varchar(80) NOT NULL, "mobile" varchar(20) NOT NULL, "account_id" integer NOT NULL REFERENCE
S "app_account" ("id") DEFERRABLE INITIALLY DEFERRED);
CREATE INDEX "app_contact_account_id_64f8cb42" ON "app_contact" ("account_id");
COMMIT;

отношение многие ко многим

В языке SQL отношение M:N достигается путем создания промежуточной реляционной таблицы, которая определяет внешние ключи для двух первичных таблиц. Таким образом, в моделях Django разработчики также могут использовать два отношения 1:N для определения отношений M:N. В то же время модели Django определяют более прямой способ моделирования отношений M:N, который заключается в определении полей типа models.ManyToManyField в любой из двух моделей.

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

from django.db import models
 
class Account(models.Model):
    user_name = models.CharField(max_length=80)
    password = models.CharField(max_length=255)
    reg_date = models.DateField()
 
class Contact(models.Model):
    account = models.ManyToManyField(Account)
    zip_code = models.CharField(max_length=10)
    address = models.CharField(max_length=80)
    mobile = models.CharField(max_length=20)

Сгенерированный SQL:

BEGIN;
--
-- Create model Account
--
CREATE TABLE "app_account" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "user_name" varchar(80) NOT NULL, "password" varchar(255) NOT NULL, "reg_date" date NOT NULL);
--
-- Create model Contact
--
CREATE TABLE "app_contact" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "zip_code" varchar(10) NOT NULL, "address" varchar(80) NOT NULL, "mobile" varchar(20) NOT NULL);
CREATE TABLE "app_contact_account" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "contact_id" integer NOT NULL REFERENCES "app_contact" ("id") DEFERRABLE INITIALLY DEFERRED, "account_id" integer NOT NULL REFE
RENCES "app_account" ("id") DEFERRABLE INITIALLY DEFERRED);
CREATE UNIQUE INDEX app_contact_account_contact_id_account_id_17ac7ce6_uniq ON "app_contact_account" ("contact_id", "account_id");
CREATE INDEX "app_contact_account_contact_id_f253b307" ON "app_contact_account" ("contact_id");
CREATE INDEX "app_contact_account_account_id_fed8aab3" ON "app_contact_account" ("account_id");
COMMIT;

Объектно-ориентированный ORM для моделей Django

Сила уровня модели Django ORM заключается в поддержке модели наследования, методов объектно-ориентированного программирования Python, метода органической привязки данных к структуре базы данных реляционных таблиц. Django поддерживает три стиля моделей наследования:

• Наследование абстрактного класса: родительский класс наследует модель слова, но не создает соответствующую таблицу данных в базовой базе данных. Столбец атрибутов родительского класса хранится в таблице данных его подкласса.
• Наследование нескольких таблиц: каждый класс модели наследования нескольких таблиц генерирует соответствующие данные управления таблицей данных в базовой базе данных.
• Наследование прокси-схемы: родительский класс используется для управления таблицами данных в базовой базе данных, в то время как подкласс не определяет столбцы данных, а определяет только метаданные, такие как метод сортировки набора баз данных запросов.

наследование абстрактного класса

Определение абстрактного базового класса достигается путем определения атрибута abstract=True в метаданных модели.

from django.db import models
 
class MessageBase(models.Model):
    id = models.AutoField(primary_key=True)
    content = models.CharField(max_length=100)
    user_name = models.CharField(max_length=80)
    pub_date = models.DateField()
 
    class Meta:
        abstract = True
 
class Moment(MessageBase):
    headline = models.CharField(max_length=50)
 
class Comment(MessageBase):
score = models.IntegerField()

Этот пример фактически генерирует 2 таблицы данных в базе данных:

• Момент таблицы данных: имеет пять полей: id, content, user_name, pub_date, заголовок
• Комментарий к таблице данных: есть пять полей: id, content, user_name, pub_date и score.

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

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

from django.db import models
 
class MessageBase(models.Model):
    id = models.AutoField(primary_key=True)
    content = models.CharField(max_length=100)
    user_name = models.CharField(max_length=80)
    pub_date = models.DateField()
 
class Moment(MessageBase):
    headline = models.CharField(max_length=50)
 
class Comment(MessageBase):
    score = models.IntegerField()

Этот пример фактически генерирует 3 таблицы данных в базе данных:

• База сообщений таблицы данных: имеет четыре поля: id, content, user_name и pub_date.
• Мониторинг таблицы данных: есть два поля messagebase_ptr_id и заголовок
• Комментарий набора данных: есть два поля с messagebase_ptr_id, оценка

Наследование прокси-модели

В наследовании прокси-модели подклассы используются только для управления данными родительского класса без фактического сохранения данных. Наследование модели прокси достигается путем определения атрибута proxy=True в метаданных подкласса.

from django.db import models
 
class Moment(models.Model):
    id = models.AutoField(primary_key=True)
    headline = models.CharField(max_length=50)
    content = models.CharField(max_length=100)
    user_name = models.CharField(max_length=80)
    pub_date = models.DateField()
 
class OrderedMoment(Moment):
    class Meta:
        proxy = True
        ordering = ["-pub_date"]

Причина использования наследования прокси-модели заключается в том, что новые функции в подклассах не влияют на поведение существующего кода в машине модели супертипа.

Наградить автора