On 12/31/2013 10:41 AM, Aymeric Augustin wrote:
On 31 déc. 2013, at 04:28, Russell Keith-Magee
<russ...@keith-magee.com <mailto:russ...@keith-magee.com>> wrote:
On Mon, Dec 30, 2013 at 8:29 PM, Aymeric Augustin
<aymeric.augus...@polytechnique.org
<mailto:aymeric.augus...@polytechnique.org>> wrote:
Logically, this would get called when the app cache is fully
populated. Running user code while the app cache isn’t ready will
backfire.
But at this point it’s too late to register listeners for the
`class_prepared` signal, so we need an early entry point. I
believe AppConfig.__init__ does the job.
An idle thought -- this problem is caused because the class_prepared
signal is currently being issued at the end of ModelBase.__new__().
Is this signal location actually a requirement? Is there any reason
that the prepare signal couldn't be decoupled from __new__(), and be
issued at the end of app configuration (at some appropriate point in
the process)? We'd need to be careful about exactly *when* the signal
was issued, and what order signals were issued to make sure ordering
doesn't change too drastically between releases -
That’s an interesting idea. To be honest, I’ve shied away from
touching ModelBase.__new__ — a 230 line method in a metaclass, what
could possibly go wrong? ;-)
In almost all cases AppConfig.setup() will be early enough.
class_prepared is the only exception I found. I’m not sure what it’s
designed for (nor that it’s a good idea at all).
Internally it is used for setting up related fields. If you have for
example ForeignKey("TargetModelDeclaredLaterOn") you can't immediately
create the ForeignKey, instead you have to wait until
TargetModelDeclaredLaterOn is prepared. Another use case seems to be
resolving references for ModelSignals (that is, you can do
pre_save.connect(somemethod, sender='auth.User'), the auth.User string
is resolved to class using class_prepared. This case should be easy
enough to do in the setup() stage instead.
If the signal was sent later on the biggest user visible change would be
that some related field references wouldn't be available as early as
they are currently. This means that QuerySet usage during import time
would be even less usable than it is now.
A possible idea is to do class preparation in two stages. Stage 1 would
be prepare class instances, set up local fields, stage 2 is set up
related fields and model inheritance. Of course, doing this is a large
refactoring better left for later. In addition this would require that
no QuerySets are created before models are set up.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/52C28CCB.2090706%40thl.fi.
For more options, visit https://groups.google.com/groups/opt_out.
