On Fri, Dec 14, 2007 at 06:42:43AM -0800, Rajesh Dhawan wrote:
> Hi Thomas,
> > I read this:http://code.djangoproject.com/wiki/Signals
> > But I couldn't find a solution to execute code,
> > if the SCGI/FastCGI/WSGI server is up, ready to handle
> > the first request.
> There is no signal like that.
> > Or is there an other way (without signals)?
> Can you describe your usecase a little? What are you wanting to do
> when the first request arrives?
There are two use cases:
1. I want to do a small self check (unittest) after restarting
the server process.
2. There is a model class for document types. Some types are
always available and created with syncdb (via signals, works fine).
The model should contain the document types somehow, so that
the programmer can access them quick.
The model class DocTypes should have a object 'system' to give them
a 'namespace':
class DocType(models.Model):
....
DocType.system.FOLDER # instance of DocType
DocType.system.UNKNOWN
...
First I coded the initialisation of the system object into the
model file. This worked because the database already contained
the needed rows. But if you try to set up a new database this
won't work.
> And what's your definition of "ready to handle the first request":
>
> - Ready to handle the first request AFTER the SCGI/FastCGI handler is
> up or BEFORE?
I use the SCGI with several processes. I think the init of the document types
need to be done after the forking of the worker processes.
> - First request ever? Or first request every time you restart the SCGI/
> FastCGI?
Every time I restart the SCGI server. At best there two signals: One
on SCGI start/restart, one after a new process was forked (if you
set max-requests to 10, the signal should be send if a new worker
process gets created).
> - What happens if your Django app runs through another WSGI server
> like, say, CherryPy WSGIServer?
I guess it would be the same. At least if you use a daemon process. It
could be different with a threaded server.
There is a third need for new signals:
I modify the session class and give them new instance methods
(new.instancemethod()). This way I don't have to patch the django
source. Up to now I do this in a middleware for every request,
but it is a waste of time since it needs to be done only once.
I guess there is a better place for code like this.
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
