Adding a hook for pre-runtime setup (ticket #5685)
Benjamin Slavin
Yesterday I had posted an inquiry to django-users about how to make
use of class_prepared. [0] Malcolm gave me a helpful reply, including
a suggestion of adding a hook to allow pre-runtime setup to occur
before executing a shell or request handler.
I have opened a ticket and coded an implementation of this suggestion
at [1]. It adds RUNTIME_SETUP_FUNCTIONS to the list of Django
settings. It serves as a list of functions to be called before
calling the runtime 'good to go'.
I wanted to get a feel for people's opinions on using this approach to
guarantee that certain code is executed before a request is processed
(or the interactive shell is loaded).
This is necessary (arguably) to setup a listener to class_prepared to
act on all models, and can be helpful to ensure that other signal
listeners are registered (no longer need to put listener registration
in __init__.py or models.py).
Any thoughts or feedback are welcome.
Thanks,
- Ben
[0] http://groups.google.com/group/django-users/browse_thread/thread/2f395d5b50086aea/
[1] http://code.djangoproject.com/ticket/5685
Andrew Durdin
>
> I wanted to get a feel for people's opinions on using this approach to
> guarantee that certain code is executed before a request is processed
> (or the interactive shell is loaded).
>
> This is necessary (arguably) to setup a listener to class_prepared to
> act on all models, and can be helpful to ensure that other signal
> listeners are registered (no longer need to put listener registration
> in __init__.py or models.py).
Well, that looks like it'll be great for registering listeners (except
perhaps for pre/post_save/delete). I've not been happy about doing it
from __init__.py, as it smells a bit (and occasionally has ended up
registering a listener more than once).
It might just help me solve another problem I've been having also -- I
need to have some setup code run after all models have been prepared,
but before the first request; but if I can successfully hook
class_prepared, I can probably use that instead.
A.
Benjamin Slavin
> Well, that looks like it'll be great for registering listeners (except
> perhaps for pre/post_save/delete).
I had overlooked the handling of these signals. They could arguably
live in models.py if they are for the same application, but across
applications this solution still wouldn't work.
My immediate thought is that we could allow pre-model instantiation
(as proposed in the ticket) and post-model instantiation hooks, but I
want to step back to think about this. I'm in meetings all morning,
but will try to dedicate some time to this later today.
Anyone with suggestions as to how to handle both cases (or perhaps a
different perspective entirely)?
- Ben
Malcolm Tredinnick
> On 10/8/07, Andrew Durdin <adu...@gmail.com> wrote:
> > Well, that looks like it'll be great for registering listeners (except
> > perhaps for pre/post_save/delete).
>
> I had overlooked the handling of these signals. They could arguably
> live in models.py if they are for the same application, but across
> applications this solution still wouldn't work.
>
> My immediate thought is that we could allow pre-model instantiation
> (as proposed in the ticket) and post-model instantiation hooks, but I
> want to step back to think about this. I'm in meetings all morning,
> but will try to dedicate some time to this later today.
I don't think we want to do this. Signals exist already for exactly this
purpose. Setting up a way to install functions prior to models being
imported but after settings are imported allows us to cover all cases
because you can install class_prepared handlers, as Andrew suggested.
The goal is to be as simple as possible here.
Regards,
Malcolm
Andrew Durdin
>
> On Mon, 2007-10-08 at 09:15 -0400, Benjamin Slavin wrote:
> >
> > My immediate thought is that we could allow pre-model instantiation
> > (as proposed in the ticket) and post-model instantiation hooks
>
> purpose. Setting up a way to install functions prior to models being
> imported but after settings are imported allows us to cover all cases
> because you can install class_prepared handlers, as Andrew suggested.
Some months ago I asked whether a signal could be sent after all
models are prepared (but before requests were handled). The reasons
behind this were complex, but it boiled down to being able to examine
a 'Search' attribute of all models to determine what properties needed
to be stored in a full text index.
This can be done with lazy loading and a class_prepared hook, but I
would much prefer to have the search index configuration happen at a
predictable time. If this could be done with a post-model signal it'd
be great, but I can't see how such a signal would be possible without
modifying Django's startup rather a bit.
A.
Paul Davis
The preruntime hook is a pretty good idea. Something to think about
though is providing a way to add callbacks to this hook that is
independant of settings.py. Otherwise 3rd party apps that want the
functionality would require changes to the settings.py beyond the
INSTALLED_APPS tuple. Granted, some might argue that as long as we're
changing the INSTALLED_APPS we might as well change the hooks tuple.
Anyway, just a thought.
Second, It might be possible to add a post-model instantiation signal
fairly easily in django.db.models.loading.AppCache._populate(). I'm
not 100% certain on this, but its there and seems like the logical
place to put a signal.
Paul
On 10/8/07, Andrew Durdin <adu...@gmail.com> wrote:
>
Malcolm Tredinnick
> Two things.
>
> The preruntime hook is a pretty good idea. Something to think about
> though is providing a way to add callbacks to this hook that is
> independant of settings.py. Otherwise 3rd party apps that want the
> functionality would require changes to the settings.py beyond the
> INSTALLED_APPS tuple. Granted, some might argue that as long as we're
> changing the INSTALLED_APPS we might as well change the hooks tuple.
> Anyway, just a thought.
Nah. Installing a third-party app may require changes to settings beyond
just INSTALLED_APPS. That's the way it works.
>
> Second, It might be possible to add a post-model instantiation signal
> fairly easily in django.db.models.loading.AppCache._populate(). I'm
> not 100% certain on this, but its there and seems like the logical
> place to put a signal.
Well, it's not a post-model instantiation, since we already have those
signals. But I've been thinking this morning, between actual work tasks,
about an app-cache-populated signal. That's probably going to have to
wait a little bit though, because I know Adrian wants to replace
INSTALLED_APPS with something more class-based in order to handle the
aliasing problems and make the app cache go away. So any signal really
only goes in after that change.
Fortunately, a pre-runtime hook gives anybody who wants it the ability
to add this signal for their own use anyway, so the initial problem
solution solves everything.
Malcolm
Paul Davis
> to add this signal for their own use anyway, so the initial problem
> solution solves everything.
>
Good point. You win this round...
Benjamin Slavin
> Something to think about though is providing a way to add
> callbacks to this hook that is independant of settings.py.
Having to modify settings.py doesn't both me here. It's done for
middleware and context processors, so it seems to fit with the rest of
the project. Additionally, it allows one to pick from a number of
functions that may be provided in a library-type application.
On 10/8/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> I've been thinking this morning, between actual work tasks,
> about an app-cache-populated signal.
I'm +0 on this approach.
From my perspective, we're trying to provide hooks into two
application states... *before* and *after* the Django runtime
environment is setup. An app-cache-populated signal would just be a
proxy for the latter. If we ever add any other dependencies to what
it means for the environment to be ready we'd need to create one more
signal.
Still, I'd rather see this than nothing at all... I'll be interested
to revisit it when Adrian's INSTALLED_APPS replacement plan lands.
- Ben
Mike Scott
I have an existing script in PHP which used shutdown_functions() and was looking for ways to do this in python. Certain use cases for this arise. (Though could be easily solved by sending to a queue server like django-queue).
If I've missed something, point me in the right direction.
Mike.
Benjamin Slavin
> Can I throw a hat in the ring and suggest a post-send-request hook?
Perhaps you mean `request_finished`? [0,1,2]
- Ben
[0] http://code.djangoproject.com/browser/django/trunk/django/core/signals.py#L2
[1] http://code.djangoproject.com/browser/django/trunk/django/core/handlers/wsgi.py#L205
[2] http://code.djangoproject.com/browser/django/trunk/django/core/handlers/modpython.py#L161
Mike Scott
Sorry all. Knew I missed it.
Thanks Ben. I might go about documenting all this sometime then. We really need to improve those docs :)