Reverse related manager should be a manager INSTANCE, not CLASS

[Jonas H.]

Please see ​https://github.com/carljm/django-model-utils/issues/31 for a problem description -- "Solution 1" is what this bug is filed for.

What I currently think of is actually pretty simple:

For the descriptor runtime related manager class hackery (this stuff here ​https://github.com/django/django/blob/d744c550d51955fd623897884446b7f34318e94d/django/db/models/fields/related.py#L484), don't subclass the original manager and then call @super(...)@ in the methods. Instead, make it a totally new class that calls instance methods.

We would probably have to extend the wrappery to replace inheritance. Or do some other type-hackery. (It can probably not get any uglier than it already is ;-)

[Carl Meyer]

I haven't looked into this enough yet to really evaluate the feasibility of turning related managers into instance wrappers rather than subclasses, but I know the current system is a major hassle for custom managers that you want used for related-object queries, because it effectively means you can't do any important configuration of the manager via instantiation (since the related manager will be a new instance of a subclass). This is wasteful: since you're instantiating the manager when you assign it as a model class attribute, you ought to be able to usefully pass it arguments there. And it leads to nasty dynamic-subclass-creation hacks to achieve things that ought to be doable via simple instantiation arguments. (See ​https://github.com/carljm/django-model-utils/blob/master/model_utils/managers.py#L172). So I'm accepting this on principle: if we can do it, it would be an improvement.

[Anssi Kääriäinen]

FWIW I am very much +1 for changing the way the related managers are handled. As said above the code can't get any uglier than it already is...