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.
Tests were failing because of:
* Models weren't being imported from their new location.
* PolymorphicManager doesn't work with non-polymorphic models, but
migrations run models' manager, so having MROBase3 with
PolymorphicManager failed.
* Some tests failed due to have assertions were being done (since they
hardcoded expected instance ids). Update tests to use comparisons
similar to #312
Tests were failing on postgres due to foreign keys pointing to missing
tables.
In order for these tables to be present, we need migrations which
declare depending on `content_type`.
Several tests were failing with django master. This is because,
apparently, IDs don't match those expected in tests, and other
test-related details.
Replace all test comparisons with assertQuerysetEqual, which is safer
and cleaner for the sort of comparison we're doing.
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'
Bastien Vallet
Diederik van der Boor
gtors
Mark Walker
Lukasz Zdun
Markus Grimm
Charlie Denton
Krzysztof Gromadzki
Hugo Osvaldo Barrera
trbs
Jerome Leclanche
Tadas Dailyda