Re: The threat of the incompletely initialized django instance
On Tuesday, April 16, 2013 8:41:26 AM UTC+2, ptone wrote: > > > > On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote: >> >> (my previous answer disappeared in googlemail, I hope that one will >> survive the sending...) >> >> Thanks for the feedback, >> >> Preston, since ticket #3591 ticket and related discusions are partially >> obsolete compared to your current works, may I just know if your current >> evolution will automatically reproduce the auto init() of the devserver >> (i.e loading models from each installed app) ? Because being able to use >> the same several times, or to set its human name, are cool features, but >> imo the most critical part at the moment is that difference between dev and >> prod inits, which can bite hard the unwary djangoer. >> >> > The approach would be more along the lines of defining a place that is > guaranteed to run at as distinct a time as possible in the startup process > - rather than trying to guarantee that all code gets imported in some > coherent way with the aim to trigger module level import code. The latter > is what we want to move away from. > > -Preston > > OK, I don't understand though in which cases one wouldn't want all his INSTALLED_APPS models to be imported at startup :? Some for the "coherent way" - doesn't python's import mechanism already ensure that modules depending on each other import themselves in a proper order (except if cyclic imports ofc) ? Regards, Pascal -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote: > > (my previous answer disappeared in googlemail, I hope that one will > survive the sending...) > > Thanks for the feedback, > > Preston, since ticket #3591 ticket and related discusions are partially > obsolete compared to your current works, may I just know if your current > evolution will automatically reproduce the auto init() of the devserver > (i.e loading models from each installed app) ? Because being able to use > the same several times, or to set its human name, are cool features, but > imo the most critical part at the moment is that difference between dev and > prod inits, which can bite hard the unwary djangoer. > > The approach would be more along the lines of defining a place that is guaranteed to run at as distinct a time as possible in the startup process - rather than trying to guarantee that all code gets imported in some coherent way with the aim to trigger module level import code. The latter is what we want to move away from. -Preston -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
(my previous answer disappeared in googlemail, I hope that one will survive the sending...) Thanks for the feedback, Preston, since ticket #3591 ticket and related discusions are partially obsolete compared to your current works, may I just know if your current evolution will automatically reproduce the auto init() of the devserver (i.e loading models from each installed app) ? Because being able to use the same several times, or to set its human name, are cool features, but imo the most critical part at the moment is that difference between dev and prod inits, which can bite hard the unwary djangoer. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
On Saturday, April 13, 2013 5:03:16 PM UTC-7, Russell Keith-Magee wrote: > > > On Sat, Apr 13, 2013 at 11:53 PM, Pakal > > wrote: > >> Hello, >> >> since version 1.2, there has been no changes about this issue, which >> still bothers me: >> https://code.djangoproject.com/ticket/14916 >> >> In summary, the django dev server loads models.py of every INSTALLED_APP, >> and thus (somehow) ensures proper initialization of models and signals. >> >> But in production, web servers do NOT load more than the strict minimum >> required by the requests they serve, so it opens the door to very subtle >> and deadly bugs, where the first requests of every new django process might >> miss a good part of the whole workflow, because miscellaneous "hooks" have >> not been registered properly. >> Doesn't this advocate a global import of all installed_apps' models.py, >> at process setup ? >> >> And more generally, people have no idea where to put their django setup >> code, so there are tons of forum threads and workarounds about this, using >> mod_wsgi's start script, or code in urls.py/settings.py, or even >> dedicated on-shot middelwares ( >> http://www.allbuttonspressed.com/projects/django-autoload). >> Wouldn't it be worth offering a place, in a project and/or in each django >> app, which will be called AFTER all models/signals are initialized, but >> BEFORE the first request is served ? Same behaviour as the "fake >> middleware" trick, but without its ugliness. >> > > The reason there hasn't been any update to ticket #14916 is that it has > been closed as a duplicate of #3591. Which it is. > > The ticket title may not make this obvious, but if you read the full > ticket history and/or search for #3591 on mailing lists, you'll quickly > find mention of an "app refactor". The purpose of the app refactor is to > provide a wrapper object that can encompass application-specific > configuration -- including things like application startup logic and signal > registration -- and to provide a guaranteed and consistent order for > startup. > > There are some draft patches floating around for the app refector; as I > understand it, the code was *almost* ready to be merged for 1.5, but there > were some last minute concerns, so it was postponed. I don't think there > have been any major discussion since then. > The work continues. Jannis and I continue to work on this project - and a set of defined "startup" hooks are one of the key features. The work will be scaled back in scope from some of the past ideas floated on #3591, some were technically not feasible, and others can be added in with later additions. At the DjangoCon sprints in Sept Russ and I did a big review of the branch that I had worked on last summer. There were some productive conversations with other core devs at that time. More details to follow hopefully in the following weeks-months. -Preston -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
On Sat, Apr 13, 2013 at 11:53 PM, Pakal wrote: > Hello, > > since version 1.2, there has been no changes about this issue, which still > bothers me: > https://code.djangoproject.com/ticket/14916 > > In summary, the django dev server loads models.py of every INSTALLED_APP, > and thus (somehow) ensures proper initialization of models and signals. > > But in production, web servers do NOT load more than the strict minimum > required by the requests they serve, so it opens the door to very subtle > and deadly bugs, where the first requests of every new django process might > miss a good part of the whole workflow, because miscellaneous "hooks" have > not been registered properly. > Doesn't this advocate a global import of all installed_apps' models.py, at > process setup ? > > And more generally, people have no idea where to put their django setup > code, so there are tons of forum threads and workarounds about this, using > mod_wsgi's start script, or code in urls.py/settings.py, or even > dedicated on-shot middelwares ( > http://www.allbuttonspressed.com/projects/django-autoload). > Wouldn't it be worth offering a place, in a project and/or in each django > app, which will be called AFTER all models/signals are initialized, but > BEFORE the first request is served ? Same behaviour as the "fake > middleware" trick, but without its ugliness. > The reason there hasn't been any update to ticket #14916 is that it has been closed as a duplicate of #3591. Which it is. The ticket title may not make this obvious, but if you read the full ticket history and/or search for #3591 on mailing lists, you'll quickly find mention of an "app refactor". The purpose of the app refactor is to provide a wrapper object that can encompass application-specific configuration -- including things like application startup logic and signal registration -- and to provide a guaranteed and consistent order for startup. There are some draft patches floating around for the app refector; as I understand it, the code was *almost* ready to be merged for 1.5, but there were some last minute concerns, so it was postponed. I don't think there have been any major discussion since then. Yours, Russ Magee %-) -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
The threat of the incompletely initialized django instance
Hello, since version 1.2, there has been no changes about this issue, which still bothers me: https://code.djangoproject.com/ticket/14916 In summary, the django dev server loads models.py of every INSTALLED_APP, and thus (somehow) ensures proper initialization of models and signals. But in production, web servers do NOT load more than the strict minimum required by the requests they serve, so it opens the door to very subtle and deadly bugs, where the first requests of every new django process might miss a good part of the whole workflow, because miscellaneous "hooks" have not been registered properly. Doesn't this advocate a global import of all installed_apps' models.py, at process setup ? And more generally, people have no idea where to put their django setup code, so there are tons of forum threads and workarounds about this, using mod_wsgi's start script, or code in urls.py/settings.py, or even dedicated on-shot middelwares ( http://www.allbuttonspressed.com/projects/django-autoload). Wouldn't it be worth offering a place, in a project and/or in each django app, which will be called AFTER all models/signals are initialized, but BEFORE the first request is served ? Same behaviour as the "fake middleware" trick, but without its ugliness. thanks in advance, regards, Pascal -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
