Reverted the change in f898f80594 that
also replaces the internal `base_objects` with `.non_polymorphic()`.
That also changed which querysets was used. Use a clean queryset
instead that has no select-related/prefetch information, etc.. like
previous versions did.
Django 1.11 uses the old manager inheritance system, unless it's
overwritten with manager_inheritance_from_future. With a class layout
like:
PolymorphicModel (abstract)
PolymorphicMPTTModel (abstract)
GenericCustomer (concrete, has objects = ...)
CustomerGroupBase (abstract, has objects = ...)
Partner (concrete, no manager)
BranchPartner (concrete, no manager)
The last level gets a normal Django Manager instead of the polymorphic
manager. Because the PolymorphicModel had a base_objects manager, this
was typically used as _default_manager. Now that the default manager is
no longer affected, it's also easier to detect why the "objects" doesn't
get the proper manager type. Using "manager_inheritance_from_future" is
recommended instead to have both the right behavior and forward
Django 2.x compatibility.
When using .defer on a PolymorphicQuerySet with multiple childs that
subclass from the same polymorphic parent model yield an error like:
>>> Base.objects.defer('ModelY___field_y')
Traceback (most recent call last):
...
FieldDoesNotExist: ModelX has no field named 'field_y'
I'm a little concerned that this loses some of the efficiencies (in
particular, chunking) from previous versions. That's something that can
probably be improved.
Thanks to @vdboor for the suggestion.
Also:
- Add missing `using` kwargs in query_translate functions.
- Add a couple unit tests for non-default database functionality.
This is unwanted behavior, and django provides much better methods for
it instead. (PolymorphicQuerySet.as_manager() / PolymorphicManager.from_queryset()
Removed compatibility_tools (because we aim to Python 2.7 and Python 3.2)
Performed 2to3 and modified
Usage of django.utils.six which adds dependency on Django >= 1.4.2