Usually, when Django users create their own polymorphic ad-hoc solution without a tool like django-polymorphic, this usually results in a variation of
result_objects = [ o.get_real_instance() for o in BaseModel.objects.filter(...) ]
which has very bad performance, as it introduces one additional
SQL query for every object in the result which is not of class
Compared to these solutions, django-polymorphic has the advantage
that it only needs 1 SQL query per object type, and not per object.
The current implementation does not use any custom SQL or Django DB layer internals - it is purely based on the standard Django ORM. Specifically, the query:
result_objects = list( ModelA.objects.filter(...) )
performs one SQL query to retrieve
ModelA objects and one additional
query for each unique derived class occurring in result_objects.
The best case for retrieving 100 objects is 1 SQL query if all are
ModelA. If 50 objects are
ModelA and 50 are
two queries are executed. The pathological worst case is 101 db queries if
result_objects contains 100 different object types (with all of them
When fetching the
it’s tempting to read the
object.polymorphic_ctype field directly.
However, this performs an additional query via the
to fetch the
from django.contrib.contenttypes.models import ContentType ctype = ContentType.objects.get_for_id(object.polymorphic_ctype_id)
This uses the
which caches the results internally.
Current relational DBM systems seem to have general problems with the SQL queries produced by object relational mappers like the Django ORM, if these use multi-table inheritance like Django’s ORM does. The “inner joins” in these queries can perform very badly. This is independent of django_polymorphic and affects all uses of multi table Model inheritance.
Please also see this post (and comments) from Jacob Kaplan-Moss.