Django includes a contenttypes application that can\ntrack all of the models installed in your Django-powered project, providing a\nhigh-level, generic interface for working with your models.
At the heart of the contenttypes application is the\nContentType model, which lives at\ndjango.contrib.contenttypes.models.ContentType. Instances of\nContentType represent and store\ninformation about the models installed in your project, and new instances of\nContentType are automatically\ncreated whenever new models are installed.
Instances of ContentType have\nmethods for returning the model classes they represent and for querying objects\nfrom those models. ContentType\nalso has a custom manager that adds methods for\nworking with ContentType and for\nobtaining instances of ContentType\nfor a particular model.
Relations between your models and\nContentType can also be used to\nenable «generic» relationships between an instance of one of your\nmodels and instances of any model you have installed.
The contenttypes framework is included in the default\nINSTALLED_APPS list created by django-admin startproject,\nbut if you’ve removed it or if you manually set up your\nINSTALLED_APPS list, you can enable it by adding\n'django.contrib.contenttypes' to your INSTALLED_APPS setting.
It’s generally a good idea to have the contenttypes framework\ninstalled; several of Django’s other bundled applications require it:
\nThe admin application uses it to log the history of each object\nadded or changed through the admin interface.
Django’s authentication framework uses it\nto tie user permissions to specific models.
ContentType modelLink to this heading#Each instance of ContentType\nhas two fields which, taken together, uniquely describe an installed\nmodel:
The name of the application the model is part of. This is taken from\nthe app_label attribute of the model, and includes only the\nlast part of the application’s Python import path;\ndjango.contrib.contenttypes, for example, becomes an\napp_label of contenttypes.
The name of the model class.
\nAdditionally, the following property is available:
\nThe human-readable name of the content type. This is taken from the\nverbose_name\nattribute of the model.
Let’s look at an example to see how this works. If you already have\nthe contenttypes application installed, and then add\nthe sites application to your\nINSTALLED_APPS setting and run manage.py migrate to install it,\nthe model django.contrib.sites.models.Site will be installed into\nyour database. Along with it a new instance of\nContentType will be\ncreated with the following values:
ContentType instancesLink to this heading#Each ContentType instance has\nmethods that allow you to get from a\nContentType instance to the\nmodel it represents, or to retrieve objects from that model:
Takes a set of valid lookup arguments for the\nmodel the ContentType\nrepresents, and does\na get() lookup\non that model, returning the corresponding object.
Returns the model class represented by this\nContentType instance.
For example, we could look up the\nContentType for the\nUser model:
>>> from django.contrib.contenttypes.models import ContentType\n>>> user_type = ContentType.objects.get(app_label='auth', model='user')\n>>> user_type\n<ContentType: user>\nAnd then use it to query for a particular\nUser, or to get access\nto the User model class:
>>> user_type.model_class()\n<class 'django.contrib.auth.models.User'>\n>>> user_type.get_object_for_this_type(username='Guido')\n<User: Guido>\nTogether,\nget_object_for_this_type()\nand model_class() enable\ntwo extremely important use cases:
Using these methods, you can write high-level generic code that\nperforms queries on any installed model – instead of importing and\nusing a single specific model class, you can pass an app_label and\nmodel into a\nContentType lookup at\nruntime, and then work with the model class or retrieve objects from it.
You can relate another model to\nContentType as a way of\ntying instances of it to particular model classes, and use these methods\nto get access to those model classes.
Several of Django’s bundled applications make use of the latter technique.\nFor example,\nthe permissions system in\nDjango’s authentication framework uses a\nPermission model with a foreign\nkey to ContentType; this lets\nPermission represent concepts like\n«can add blog entry» or «can delete news story».
ContentTypeManagerLink to this heading#ContentType also has a custom\nmanager, ContentTypeManager,\nwhich adds the following methods:
Clears an internal cache used by\nContentType to keep track\nof models for which it has created\nContentType instances. You\nprobably won’t ever need to call this method yourself; Django will call\nit automatically when it’s needed.
Lookup a ContentType by ID.\nSince this method uses the same shared cache as\nget_for_model(),\nit’s preferred to use this method over the usual\nContentType.objects.get(pk=id)
Takes either a model class or an instance of a model, and returns the\nContentType instance\nrepresenting that model. for_concrete_model=False allows fetching\nthe ContentType of a proxy\nmodel.
Takes a variadic number of model classes, and returns a dictionary\nmapping the model classes to the\nContentType instances\nrepresenting them. for_concrete_models=False allows fetching the\nContentType of proxy\nmodels.
Returns the ContentType\ninstance uniquely identified by the given application label and model\nname. The primary purpose of this method is to allow\nContentType objects to be\nreferenced via a natural key\nduring deserialization.
The get_for_model() method is especially\nuseful when you know you need to work with a\nContentType but don’t\nwant to go to the trouble of obtaining the model’s metadata to perform a manual\nlookup:
>>> from django.contrib.auth.models import User\n>>> ContentType.objects.get_for_model(User)\n<ContentType: user>\nAdding a foreign key from one of your own models to\nContentType allows your model to\neffectively tie itself to another model class, as in the example of the\nPermission model above. But it’s possible\nto go one step further and use\nContentType to enable truly\ngeneric (sometimes called «polymorphic») relationships between models.
A simple example is a tagging system, which might look like this:
\nfrom django.contrib.contenttypes.fields import GenericForeignKey\nfrom django.contrib.contenttypes.models import ContentType\nfrom django.db import models\n\nclass TaggedItem(models.Model):\n tag = models.SlugField()\n content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)\n object_id = models.PositiveIntegerField()\n content_object = GenericForeignKey('content_type', 'object_id')\n\n def __str__(self):\n return self.tag\nA normal ForeignKey can only «point\nto» one other model, which means that if the TaggedItem model used a\nForeignKey it would have to\nchoose one and only one model to store tags for. The contenttypes\napplication provides a special field type (GenericForeignKey) which\nworks around this and allows the relationship to be with any\nmodel:
There are three parts to setting up a\nGenericForeignKey:
Give your model a ForeignKey\nto ContentType. The usual\nname for this field is «content_type».
Give your model a field that can store primary key values from the\nmodels you’ll be relating to. For most models, this means a\nPositiveIntegerField. The usual name\nfor this field is «object_id».
Give your model a\nGenericForeignKey, and\npass it the names of the two fields described above. If these fields\nare named «content_type» and «object_id», you can omit this – those\nare the default field names\nGenericForeignKey will\nlook for.
If False, the field will be able to reference proxy models. Default\nis True. This mirrors the for_concrete_model argument to\nget_for_model().
This will enable an API similar to the one used for a normal\nForeignKey;\neach TaggedItem will have a content_object field that returns the\nobject it’s related to, and you can also assign to that field or use it when\ncreating a TaggedItem:
>>> from django.contrib.auth.models import User\n>>> guido = User.objects.get(username='Guido')\n>>> t = TaggedItem(content_object=guido, tag='bdfl')\n>>> t.save()\n>>> t.content_object\n<User: Guido>\nIf the related object is deleted, the content_type and object_id fields\nremain set to their original values and the GenericForeignKey returns\nNone:
>>> guido.delete()\n>>> t.content_object # returns None\nDue to the way GenericForeignKey\nis implemented, you cannot use such fields directly with filters (filter()\nand exclude(), for example) via the database API. Because a\nGenericForeignKey isn’t a\nnormal field object, these examples will not work:
# This will fail\n>>> TaggedItem.objects.filter(content_object=guido)\n# This will also fail\n>>> TaggedItem.objects.get(content_object=guido)\nLikewise, GenericForeignKeys\ndoes not appear in ModelForms.
The relation on the related object back to this object doesn’t exist by\ndefault. Setting related_query_name creates a relation from the\nrelated object back to this one. This allows querying and filtering\nfrom the related object.
If you know which models you’ll be using most often, you can also add\na «reverse» generic relationship to enable an additional API. For example:
\nfrom django.contrib.contenttypes.fields import GenericRelation\nfrom django.db import models\n\nclass Bookmark(models.Model):\n url = models.URLField()\n tags = GenericRelation(TaggedItem)\nBookmark instances will each have a tags attribute, which can\nbe used to retrieve their associated TaggedItems:
>>> b = Bookmark(url='https://www.djangoproject.com/')\n>>> b.save()\n>>> t1 = TaggedItem(content_object=b, tag='django')\n>>> t1.save()\n>>> t2 = TaggedItem(content_object=b, tag='python')\n>>> t2.save()\n>>> b.tags.all()\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nDefining GenericRelation with\nrelated_query_name set allows querying from the related object:
tags = GenericRelation(TaggedItem, related_query_name='bookmarks')\nThis enables filtering, ordering, and other query operations on Bookmark\nfrom TaggedItem:
>>> # Get all tags belonging to bookmarks containing `django` in the url\n>>> TaggedItem.objects.filter(bookmarks__url__contains='django')\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nOf course, if you don’t add the reverse relationship, you can do the\nsame types of lookups manually:
\n>>> b = Bookmark.objects.get(url='https://www.djangoproject.com/')\n>>> bookmark_type = ContentType.objects.get_for_model(b)\n>>> TaggedItem.objects.filter(content_type__pk=bookmark_type.id, object_id=b.id)\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nJust as GenericForeignKey\naccepts the names of the content-type and object-ID fields as\narguments, so too does\nGenericRelation;\nif the model which has the generic foreign key is using non-default names\nfor those fields, you must pass the names of the fields when setting up a\nGenericRelation to it. For example, if the TaggedItem model\nreferred to above used fields named content_type_fk and\nobject_primary_key to create its generic foreign key, then a\nGenericRelation back to it would need to be defined like so:
tags = GenericRelation(\n TaggedItem,\n content_type_field='content_type_fk',\n object_id_field='object_primary_key',\n)\nNote also, that if you delete an object that has a\nGenericRelation, any objects\nwhich have a GenericForeignKey\npointing at it will be deleted as well. In the example above, this means that\nif a Bookmark object were deleted, any TaggedItem objects pointing at\nit would be deleted at the same time.
Unlike ForeignKey,\nGenericForeignKey does not accept\nan on_delete argument to customize this\nbehavior; if desired, you can avoid the cascade-deletion simply by not using\nGenericRelation, and alternate\nbehavior can be provided via the pre_delete\nsignal.
Django’s database aggregation API works with a\nGenericRelation. For example, you\ncan find out how many tags all the bookmarks have:
>>> Bookmark.objects.aggregate(Count('tags'))\n{'tags__count': 3}\nThe django.contrib.contenttypes.forms module provides:
A formset factory, generic_inlineformset_factory(), for use with\nGenericForeignKey.
Returns a GenericInlineFormSet using\nmodelformset_factory().
You must provide ct_field and fk_field if they are different from\nthe defaults, content_type and object_id respectively. Other\nparameters are similar to those documented in\nmodelformset_factory() and\ninlineformset_factory().
The for_concrete_model argument corresponds to the\nfor_concrete_model\nargument on GenericForeignKey.
The django.contrib.contenttypes.admin module provides\nGenericTabularInline and\nGenericStackedInline (subclasses of\nGenericInlineModelAdmin)
These classes and functions enable the use of generic relations in forms\nand the admin. See the model formset and\nadmin documentation for more\ninformation.
\nThe GenericInlineModelAdmin\nclass inherits all properties from an\nInlineModelAdmin class. However,\nit adds a couple of its own for working with the generic relation:
The name of the\nContentType foreign key\nfield on the model. Defaults to content_type.
The name of the integer field that represents the ID of the related\nobject. Defaults to object_id.
Subclasses of GenericInlineModelAdmin with stacked and tabular\nlayouts, respectively.