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.
Using model_cls.add_to_class() calls Manager.contribute_to_class(),
which then sets the attribute to an instance of ManagerDescriptor. In
the case of _default_manager, this behavior differs from Django's, as
_default_manager is set to the manager instance itself, not its
descriptor. This is why it is normally possible to access default_manager
from a model instance.
fixes#96
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
As more methods are added to the PolymorphicModel, the attr dict changes
ordering in the meta class. By making the ordering of managers
consistent, this problem no longer occurs.
* The custom manager was not assigned to _default_manager;
get_first_user_defined_manager() always returned None
* The PolymorphicManager couldn't remember it's custom queryset;
a RelatedManager creates a new instance of a manager, so the queryset
parameter should be known at class-level, not object level.
* The old method of providing a custom queryset class has been deprecated.
The reason polymorphic broke was because it couldn't find some managers
anymore in the inheritance tree. Django 1.5 removes these and replaces
them with an `AbstractManagerDescriptor`. This patch restores those objects
the regular Django dumpdata command now automatically works correctly
for polymorphic models and all Django versions
(this is handled by PolymorphicModelBase now).
Testing for dumpdata has been added.
- added python2.4 compatibility. Contributed by Charles Leifer. Thanks!
- general reorganization of the code - there is no single polymorphic.py module anymore,
so d-p now needs to be installed as a regular Django app
- polymorphic.VERSION/get_version added
- version numbering started: V0.5 beta