This also replaces the PolymorphicInlineModelAdmin.get_get_child_inline_instance()
and BasePolymorphicModelFormSet._construct_form() lookup with UnsupportedChildType
(cherry picked from commit cafaf95f06)
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'
(cherry picked from commit 9500a21f82)
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.
Not all projects have queryset issues, for example the class could be a
leaf that doesn't get inherited further.
class PolymorphicModel
class ContentItem
class TextItem <-- gets error, but it's the leaf anyway.
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.
Sometimes the tests failed because these objects had IDs that differed
from expectations. As the IDs are not relevant to this test, I have
replaced the exact string match with a regex match that accepts any ID.
This silences one instance of the warning that's being printed in tests
for versions of Django before 2.0:
> RemovedInDjango20Warning: Managers from concrete parents will soon
> qualify as default managers if they appear before any other managers
> in the MRO.