Opened 7 years ago

Closed 7 years ago

#27664 closed Bug (needsinfo)

Manager.contribute_to_class() is called with abstract model rather than concrete model

Reported by: Johannes Maron Owned by: nobody
Component: Database layer (models, ORM) Version: 1.10
Severity: Normal Keywords:
Cc: info@…, Loic Bistuer Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Since 1.10 Manager.contribute_to_class gets called with the model on which the manager is defined instead of the subclass.
Before that it used to be called for all sub models with the proper class.

You can easily reproduce that by running this in both version 1.9 and 1.10. model will be different.

class MyManager(models.Manager):
 		 
     def contribute_to_class(self, model, name):
         super().contribute_to_class(model, name)
         print(model)

class AbstractModel(models.Model):
    objects = MyManager()
    class Meta:
        abstract = True

class ContcreteModel(AbstractModel):
    pass

This change has not been documented in the release notes and also seems counter intuitive. Contribute to class should be called with the concrete model.

Change History (4)

comment:1 by Tim Graham, 7 years ago

Cc: Loic Bistuer added

This changed in 3a47d42fa33012b2156bf04058d933df6b3082d2 - Fixed #20932, #25897 -- Streamlined manager inheritance.

I'm uncertain if the new behavior is intended or if it needs clarification in the release notes, however, as far as I know contribute_to_class() is a private API so backwards compatibility and documentation changes there isn't a high priority.

comment:2 by Tim Graham, 7 years ago

Summary: contribute_to_class is called with wrong model classManager.contribute_to_class() is called with abstract model rather than concrete model

comment:3 by Johannes Maron, 7 years ago

Hi Tim,

I agree, it is not documented, but I guess it's not to uncommon for third party libraries to make use of contribute_to_class be it on Managers or Fields.

Regardless, the documentation says, that the manager will be inherited. So I would presume the having the attribute on a super class is the same than having the attribute on the sub class.

This is not the case.

I'm not sure if this is just a matter of documentation or if it should be changed. My first guess would be to change it. It seems more intuitive to me. But I really like the that the new Manager design is less complex. If there isn't an easy solution. This shouldn't be changed.

comment:4 by Tim Graham, 7 years ago

Resolution: needsinfo
Status: newclosed

Absent a patch or explanation of why the change is needed, I don't know what to do here. Feel free to investigate and offer a patch. I have a feeling that "fixing" this requires reintroducing the complexity that Loic's patch removed.

Note: See TracTickets for help on using tickets.
Back to Top