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
Diederik van der Boor
gilgamezh
Frankie Dintino
Tomas Peterka
Ben Konrath
German M. Bravo
Martin Brochhaus
Jonas Obrist
Bert Constantin