Фреймворк contenttypes
Django включает приложение contenttypes, которое может отслеживать все модели, установленные в вашем проекте Django, предоставляя высокоуровневый общий интерфейс для работы с вашими моделями.
Обзор
В основе приложения contenttypes лежит модель ContentType, которая находится в django.contrib.contenttypes.models.ContentType. Экземпляры ContentType представляют и хранят информацию о моделях, установленных в вашем проекте, и новые экземпляры ContentType автоматически создаются при установке новых моделей.
Экземпляры ContentType имеют методы для возврата представляемых ими классов моделей и для запроса объектов из этих моделей. ContentType также имеет пользовательского менеджера, который добавляет методы для работы с ContentType и для получения экземпляров ContentType для определённой модели.
Связи между вашими моделями и ContentType также могут использоваться для включения «общих» отношений между экземпляром одной из ваших моделей и экземплярами любой установленной вами модели.
Установка фреймворка contenttypes
Фреймворк contenttypes включен в стандартный список INSTALLED_APPS, созданный django-admin startproject, но если вы его удалили или вручную настроили список INSTALLED_APPS, вы можете включить его, добавив 'django.contrib.contenttypes' в ваш параметр INSTALLED_APPS.
В целом, рекомендуется иметь установленный фреймворк contenttypes; ряд других объединённых приложений Django требуют его:
- Приложение администрирования использует его для регистрации истории каждого добавленного или изменённого объекта через интерфейс администрирования.
- Django
authentication frameworkиспользует его для привязки разрешений пользователей к конкретным моделям.
Модель ContentType
-
class ContentType -
Каждый экземпляр
ContentTypeимеет два поля, которые вместе уникально описывают установленную модель:-
app_label -
Имя приложения, к которому принадлежит модель. Оно взято из атрибута
app_labelмодели и включает только последнюю часть пути импорта приложения;django.contrib.contenttypes, например, становится атрибутомapp_labelcontenttypes.
-
model -
Имя класса модели.
Кроме того, доступно следующее свойство:
-
name -
Человекочитаемое имя типа содержимого. Оно взято из атрибута
verbose_nameмодели.
-
Рассмотрим пример, чтобы увидеть, как это работает. Если у вас уже установлено приложение contenttypes, и вы добавляете the sites application в ваш параметр INSTALLED_APPS и запускаете manage.py migrate, чтобы установить его, модель django.contrib.sites.models.Site будет установлена в вашей базе данных. Вместе с ней будет создан новый экземпляр ContentType со следующими значениями:
-
app_labelбудет установлено в'sites'(последняя часть пути Pythondjango.contrib.sites). -
modelбудет установлено в'site'.
Методы экземпляров ContentType
Каждый экземпляр ContentType имеет методы, которые позволяют получить из экземпляра ContentType представляемую им модель или извлечь объекты из этой модели:
-
ContentType.get_object_for_this_type(**kwargs) -
Принимает набор допустимых аргументов поиска для модели, которую представляет
ContentType, и выполняетa get() lookupдля этой модели, возвращая соответствующий объект.
-
ContentType.model_class() -
Возвращает класс модели, представленный этим экземпляром
ContentType.
Например, мы можем найти ContentType для модели User:
>>> from django.contrib.contenttypes.models import ContentType >>> user_type = ContentType.objects.get(app_label='auth', model='user') >>> user_type <ContentType: user>
А затем использовать его для запроса конкретного User или для получения доступа к классу модели User.
>>> user_type.model_class() <class 'django.contrib.auth.models.User'> >>> user_type.get_object_for_this_type(username='Guido') <User: Guido>
Вместе get_object_for_this_type() и model_class() позволяют реализовать два чрезвычайно важных случая использования:
- Используя эти методы, вы можете написать высокоуровневый универсальный код, который выполняет запросы к любой установленной модели — вместо импорта и использования одного конкретного класса модели, вы можете передавать
app_labelиmodelв запрос кContentTypeво время выполнения, а затем работать с классом модели или извлекать объекты из него. - Вы можете связать другую модель с
ContentTypeкак способ привязки экземпляров к конкретным классам моделей, и использовать эти методы для получения доступа к этим классам моделей.
Несколько встроенных приложений Django используют последний метод. Например, the permissions system в рамках системы аутентификации Django использует модель Permission с внешним ключом к ContentType; это позволяет Permission представлять такие понятия, как «может добавлять записи в блог» или «может удалять новости».
Менеджер ContentTypeManager
-
class ContentTypeManager -
ContentTypeтакже имеет пользовательский менеджерContentTypeManager, который добавляет следующие методы:-
clear_cache() -
Очищает внутрен кэш, используемый
ContentTypeдля отслеживания моделей, для которых были созданы экземплярыContentType. Вам, скорее всего, никогда не придётся вызывать этот метод самостоятельно; Django вызовет его автоматически при необходимости.
-
get_for_id(id) -
Поиск
ContentTypeпо идентификатору. Поскольку этот метод использует тот же общий кэш, что иget_for_model(), предпочтительнее использовать этот метод вместо обычногоContentType.objects.get(pk=id)
-
get_for_model(model, for_concrete_model=True) -
Принимает класс модели или экземпляр модели и возвращает экземпляр
ContentType, представляющий эту модель.for_concrete_model=Falseпозволяет получитьContentTypeпрокси-модели.
-
get_for_models(*models, for_concrete_models=True) -
Принимает переменное число классов моделей и возвращает словарь, сопоставляющий классы моделей с экземплярами
ContentType, представляющими их.for_concrete_models=Falseпозволяет получитьContentTypeпрокси-моделей.
-
get_by_natural_key(app_label, model) -
Возвращает экземпляр
ContentType, однозначно идентифицированный заданным именем приложения и именем модели. Основное назначение этого метода — позволить объектамContentTypeссылаться с помощью естественного ключа во время десериализации.
-
Метод get_for_model() особенно полезен, когда вы знаете, что вам нужно работать с ContentType, но не хотите утруждать себя получением метаданных модели для выполнения ручного поиска:
>>> from django.contrib.auth.models import User >>> ContentType.objects.get_for_model(User) <ContentType: user>
Обобщенные связи
Добавление внешнего ключа от одной из ваших собственных моделей к ContentType позволяет вашей модели эффективно привязываться к другому классу моделей, как в примере модели Permission выше. Но можно пойти ещё дальше и использовать ContentType для создания действительно обобщенных (иногда называемых «полиморфных») отношений между моделями.
Например, это можно использовать для системы тегирования так:
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType
from django.db import models
class TaggedItem(models.Model):
tag = models.SlugField()
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey('content_type', 'object_id')
def __str__(self):
return self.tag
Обычный ForeignKey может «указывать» только на одну другую модель, что означает, что если модель TaggedItem использовала ForeignKey, ей пришлось бы выбрать одну и только одну модель для хранения тегов. Приложение contenttypes предоставляет специальный тип поля (GenericForeignKey) , который обходит это и позволяет устанавливать отношение с любой моделью:
-
class GenericForeignKey -
Есть три части настройки
GenericForeignKey:- Добавьте в вашу модель
ForeignKeyкContentType. Обычно это поле называется «content_type». - Добавьте в вашу модель поле, которое может хранить значения первичных ключей из моделей, к которым вы хотите установить связь. Для большинства моделей это
PositiveIntegerField. Обычно это поле называется «object_id». - Добавьте
GenericForeignKeyв вашу модель и передайте имена двух полей, описанных выше. Если эти поля называются «content_type» и «object_id», это можно опустить —GenericForeignKeyбудут искать эти поля по умолчанию.
-
for_concrete_model -
Если
False, поле сможет ссылаться на прокси-модели. По умолчаниюTrue. Это отражает аргументfor_concrete_modelкget_for_model().
- Добавьте в вашу модель
Совместимость типов первичных ключей
Поле «object_id» не обязательно должно быть того же типа, что и поля первичных ключей в связанных моделях, но значения их первичных ключей должны быть преобразуемы в тот же тип, что и поле «object_id», с помощью метода get_db_prep_value().
Например, если вы хотите разрешить обобщенные отношения к моделям с полями первичного ключа типа IntegerField или CharField, вы можете использовать CharField для поля «object_id» в вашей модели, так как целые числа могут быть преобразованы в строки методом get_db_prep_value().
Для максимальной гибкости можно использовать TextField, у которого нет максимальной длины, однако это может привести к значительным потерям производительности в зависимости от базы данных.
Нет универсального решения для выбора наилучшего типа поля. Вы должны оценить модели, к которым вы ожидаете установить связь, и определить, какое решение будет наиболее эффективным для вашего случая использования.
Сериализация ссылок на объекты ContentType
Если вы сериализуете данные (например, при генерации fixtures) из модели, которая реализует общие отношения, вам, вероятно, следует использовать естественный ключ для уникальной идентификации связанных объектов ContentType. См. естественные ключи и dumpdata --natural-foreign для получения дополнительной информации.
Это позволит использовать API, аналогичный API, используемому для обычного ForeignKey; каждый TaggedItem будет иметь поле content_object, которое возвращает связанный с ним объект, и вы также можете назначить значение этому полю или использовать его при создании TaggedItem:
>>> from django.contrib.auth.models import User >>> guido = User.objects.get(username='Guido') >>> t = TaggedItem(content_object=guido, tag='bdfl') >>> t.save() >>> t.content_object <User: Guido>
Если связанный объект удален, поля content_type и object_id сохраняют свои первоначальные значения, а GenericForeignKey возвращает None:
>>> guido.delete() >>> t.content_object # returns None
Из-за способа реализации GenericForeignKey вы не можете напрямую использовать такие поля с фильтрами (filter() и exclude(), например) через API базы данных. Поскольку GenericForeignKey не является обычным объектом поля, эти примеры не будут работать:
# This will fail >>> TaggedItem.objects.filter(content_object=guido) # This will also fail >>> TaggedItem.objects.get(content_object=guido)
Аналогично, GenericForeignKey не отображаются в ModelForm.
Обратные общие отношения
-
class GenericRelation -
-
Связь с объектом, возвращающим этот объект, по умолчанию отсутствует. Установка
related_query_nameсоздает отношение от связанного объекта обратно к этому объекту. Это позволяет выполнять запросы и фильтрацию со связанного объекта.
-
Если вы знаете, какие модели вы чаще всего будете использовать, вы также можете добавить «обратное» общее отношение для активации дополнительного API. Например:
from django.contrib.contenttypes.fields import GenericRelation
from django.db import models
class Bookmark(models.Model):
url = models.URLField()
tags = GenericRelation(TaggedItem)
Экземпляры Bookmark будут иметь атрибут tags, который можно использовать для получения связанных с ними TaggedItems:
>>> b = Bookmark(url='https://www.djangoproject.com/') >>> b.save() >>> t1 = TaggedItem(content_object=b, tag='django') >>> t1.save() >>> t2 = TaggedItem(content_object=b, tag='python') >>> t2.save() >>> b.tags.all() <QuerySet [<TaggedItem: django>, <TaggedItem: python>]>
Определение GenericRelation со значением related_query_name позволяет выполнять запросы со связанного объекта:
tags = GenericRelation(TaggedItem, related_query_name='bookmark')
Это позволяет фильтровать, сортировать и выполнять другие операции запроса на Bookmark из TaggedItem:
>>> # Get all tags belonging to bookmarks containing `django` in the url >>> TaggedItem.objects.filter(bookmark__url__contains='django') <QuerySet [<TaggedItem: django>, <TaggedItem: python>]>
Конечно, если вы не добавили related_query_name, вы можете выполнить те же типы запросов вручную:
>>> bookmarks = Bookmark.objects.filter(url__contains='django') >>> bookmark_type = ContentType.objects.get_for_model(Bookmark) >>> TaggedItem.objects.filter(content_type__pk=bookmark_type.id, object_id__in=bookmarks) <QuerySet [<TaggedItem: django>, <TaggedItem: python>]>
Так же, как GenericForeignKey принимает имена полей типа содержимого и идентификатора объекта в качестве аргументов, так и GenericRelation; если модель, которая имеет общий внешний ключ, использует имена полей, отличные от стандартных, вам необходимо передать имена полей при настройке GenericRelation. Например, если модель TaggedItem, упомянутая выше, использовала поля с именами content_type_fk и object_primary_key для создания общего внешнего ключа, тогда GenericRelation к ней должен быть определён так:
tags = GenericRelation(
TaggedItem,
content_type_field='content_type_fk',
object_id_field='object_primary_key',
)
Обратите также внимание, что если вы удаляете объект, имеющий GenericRelation, любые объекты, имеющие GenericForeignKey, указывающие на него, также будут удалены. В примере выше это означает, что если будет удалён объект Bookmark, любые объекты TaggedItem , указывающие на него, будут удалены одновременно.
В отличие от ForeignKey, GenericForeignKey не принимает аргумент on_delete для настройки этого поведения; если это необходимо, вы можете избежать каскадного удаления, не используя GenericRelation, и альтернативное поведение можно обеспечить с помощью сигнала pre_delete.
Общие отношения и агрегация
API агрегации базы данных Django работает с GenericRelation. Например, вы можете узнать, сколько тегов имеют все закладки:
>>> Bookmark.objects.aggregate(Count('tags'))
{'tags__count': 3}
Общее отношение в формах
Модуль django.contrib.contenttypes.forms предоставляет:
BaseGenericInlineFormSet- Фабрику наборов форм
generic_inlineformset_factory()для использования сGenericForeignKey.
-
class BaseGenericInlineFormSet
-
generic_inlineformset_factory(model, form=ModelForm, formset=BaseGenericInlineFormSet, ct_field="content_type", fk_field="object_id", fields=None, exclude=None, extra=3, can_order=False, can_delete=True, max_num=None, formfield_callback=None, validate_max=False, for_concrete_model=True, min_num=None, validate_min=False) -
Возвращает набор форм
GenericInlineFormSet, используяmodelformset_factory().Вы должны предоставить
ct_fieldиfk_field, если они отличаются от значений по умолчанию,content_typeиobject_idсоответственно. Другие параметры аналогичны документации вmodelformset_factory()иinlineformset_factory().Аргумент
for_concrete_modelсоответствует аргументуfor_concrete_modelвGenericForeignKey.
Общие отношения в админке
Модуль django.contrib.contenttypes.admin предоставляет GenericTabularInline и GenericStackedInline (подклассы GenericInlineModelAdmin)
Эти классы и функции позволяют использовать общие отношения в формах и админке. См. документацию по наборам форм моделей и админке для получения дополнительной информации.
-
class GenericInlineModelAdmin -
Класс
GenericInlineModelAdminнаследует все свойства от классаInlineModelAdmin. Однако он добавляет несколько своих собственных для работы с обобщенной ссылкой:-
ct_field -
Имя поля внешнего ключа
ContentTypeв модели. По умолчаниюcontent_type.
-
ct_fk_field -
Имя целочисленного поля, представляющего идентификатор связанного объекта. По умолчанию
object_id.
-
-
class GenericTabularInline
-
class GenericStackedInline -
Подклассы
GenericInlineModelAdminс выравниванием в виде стека и таблицы соответственно.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/3.0/ref/contrib/contenttypes/