#26640 closed Bug (wontfix)
class_prepared is not a ModelSignal and differs from documentation
Reported by: | Alex Hill | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
A few minor issues with class_prepared:
- it's documented as a model signal, and so able to be called with lazy references, but it isn't one and can't be.
Model signals sender model can be lazily referenced when connecting a receiver by specifying its full application label.
- it's documented as being sent after the model is registered, but it's actually sent just before
Sent whenever a model class has been “prepared” – that is, once model has been defined and registered with Django’s model system.
In ModelBase.__new__()
:
... new_class._prepare() # class_prepared.send() is called at the end of this method new_class._meta.apps.register_model(new_class._meta.app_label, new_class) return new_class
- it's instantiated with
providing_args=["class"]
, but it doesn't provide aclass
argument
All three addressed in PR 6628.
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 9 years ago
I've added some comments in that ticket. I think deprecating the signal is probably a good idea.
Would deprecating the class_prepared
and fixing the issues in this ticket be mutually exclusive?
#24313 suggests to deprecated the
class_prepared
signal. Do you see a reason not to move forward with that instead?