When calling `select_related()` with an empty list of arguments [1], Django will
try to prefetch some data by doing some first level joints with the related
classes.
This can lead to obvious negative performance impact, but this also breaks some
workarounds for having inheritance for foreign keys [2], as those solutions rely
on lazy evaluation of the related object.
[1]: a4e6030904/django/db/models/query.py (L1051)
Only passing an explicit `None` to `select_related` will disable the magic.
[2]: https://github.com/jazzband/django-model-utils/issues/11
As examples, here are the generated SQL requests in
InheritanceManagerRelatedTests.test_get_method_with_select_subclasses_check_for_useless_join:
* without this fix, without adding `.select_related(None)`
```sql
SELECT
"tests_inheritancemanagertestparent"."id",
"tests_inheritancemanagertestparent"."non_related_field_using_descriptor",
"tests_inheritancemanagertestparent"."related_id",
"tests_inheritancemanagertestparent"."normal_field",
"tests_inheritancemanagertestparent"."related_self_id",
"tests_inheritancemanagertestchild4"."other_onetoone_id",
"tests_inheritancemanagertestchild4"."parent_ptr_id", T3."id",
T3."non_related_field_using_descriptor", T3."related_id", T3."normal_field",
T3."related_self_id"
FROM
"tests_inheritancemanagertestchild4"
INNER JOIN
"tests_inheritancemanagertestparent" ON
("tests_inheritancemanagertestchild4"."parent_ptr_id" = "tests_inheritancemanagertestparent"."id")
INNER JOIN
"tests_inheritancemanagertestparent" T3 ON
("tests_inheritancemanagertestchild4"."other_onetoone_id" = T3."id")
WHERE
"tests_inheritancemanagertestchild4"."parent_ptr_id" = 191
```
* with either the fix, or by adding `.select_related(None)` after `.select_subclasses()`
```sql
SELECT
"tests_inheritancemanagertestparent"."id",
"tests_inheritancemanagertestparent"."non_related_field_using_descriptor",
"tests_inheritancemanagertestparent"."related_id",
"tests_inheritancemanagertestparent"."normal_field",
"tests_inheritancemanagertestparent"."related_self_id",
"tests_inheritancemanagertestchild4"."other_onetoone_id",
"tests_inheritancemanagertestchild4"."parent_ptr_id"
FROM
"tests_inheritancemanagertestchild4"
INNER JOIN
"tests_inheritancemanagertestparent" ON
("tests_inheritancemanagertestchild4"."parent_ptr_id" = "tests_inheritancemanagertestparent"."id")
WHERE
"tests_inheritancemanagertestchild4"."parent_ptr_id" = 191
```
* - add django 3.0 to the test matrix
- drop six
* add entry in CHANGES
* remove context kwarg
* fix test with DeferredAttribute
* rename StringyDescriptor's name to attname
* Fix flake8
* Drop support for Django 1.11 because the API are not compatibles anymore with Django 3.0
* Try to fix tests.
* Define model for the field mock.
* Simplifies the code.
* Properly mock the field.
* Typo
* Use the new API field name.
* Call it attname
* Grab the field instance from the model.
* Use postgres in travis tests.
* Django 2.0.1 minimum is needed.
* Update Changelog to tell about breaking Django 1.11.
* Update changelog to tell about Django 3.0 support.
* @natim review.
* Add the join manager + tests
* Documentation for join manager
* Use order_by for consistent tests
* Use postgres instead sqlite for tests for better reliability
* Fix coverage
* Drop django 1.8
Django starting with 1.9 switched to using a class to provide an
iterator for the querymanager. Between 1.9 and 1.10 changes slowly
stopped referencing that function and instead started calling
_iterator_class directly.
As the functionality model-utils is patching has moved, this patch moves
the iterator logic to a class to match the changes that have been made
in Django in version 1.9.
As Django 1.8 is a LTS release that is still supported, iterator()
is retained in the InheritanceQuerySetMixin and can be removed when
support for Django 1.8 is removed. This goes for the try-except in the
import statements as well.
InheritanceQuerySet with `select_subclasses` applied as strings
raised AttributeError exception.
Adds a new test case `test_dj19_values_list_on_select_subclasses`
InheritanceQuerySetMixin._clone signature conflicts with django
ValuesQuerySet._clone code which calls super like this:
"c = super(ValuesQuerySet, self)._clone(klass, **kwargs)"
By itself, .instance_of(*models) will actually call select_subclasses(*models),
which results in just those objects being cast to subclasses.
However, if you want the casting to grandchildren (which is supported only in
django 1.6+), then you may use an extra call to .select_subclasses() (without
arguments, to select all subclasses).
It doesn't deal with @kezabelle's discussion of mixed-use of select_subclasses/
instance_of, I still need to look at that.
But it does pass all current tests...
This is based upon the feature in django-polymorphic, where you
can do:
SuperClass.objects.instance_of(SubClass)
This will result in only objects of the subclass being fetched.
Note: this works with any queryset, keeping the filtering and
ordering applied there.
When subclassing Django will copy managers from the ancestor class. Copying in turn calls `copy.copy()` which checks whether the object uses `__slots__` or `__dict__`. This could result in the manager calling `self.get_queryset()` before all models get registered with the ORM.
