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.
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`.
Diederik van der Boor
Charlie Denton
Krzysztof Gromadzki
Hugo Osvaldo Barrera