Reading your description again, it seems like you apply the condition to
default managers as well. Default managers are not "specific to the class they
are defined on", and I see no problem in their inheritance. In particular:
... some fields, no manager
... some fields, still no manager
Now, are you suggesting that Comment.objects must be defined explicitly? I find
On Saturday 06 February 2016 18:07:22 Alex Poleha wrote:
> Thank you for the suggestion. Pull request is adjusted to give deprecation
> warning instead of raising AttributeError.
> Yes, to silence the warning manager need to be be added to any subclass
> explicitly. It is explained in documentation
> and-model-inheritance> for ages, so I don't think there would be a problem.
> среда, 3 февраля 2016 г., 19:18:24 UTC+3 пользователь Tim Graham написал:
> > Could this go through a deprecation where any use of the inherited
> > managers to be removed will raise a warning for a couple releases? If
> > anyone is relying on the behavior, they just need to add the managers to
> > any subclasses, correct?
> > On Wednesday, February 3, 2016 at 9:16:41 AM UTC-5, Alex Poleha wrote:
> >> Hi.
> >> According to documentation
> >> <https://docs.djangoproject.com/en/1.9/topics/db/managers/#custom-manage
> >> rs-and-model-inheritance> managers defined on non-abstract base classes
> >> are not inherited by child classes. In fact they're inherited via
> >> python MRO. I made pull request
> >> <https://github.com/django/django/pull/5797
> to fix it. I find this
> >> inheritance embarrassing due to reasons, explained in documentation:
> >> 1. Managers defined on non-abstract base classes are *not* inherited