On Thursday, February 17, 2011 6:37:56 AM UTC, lawgon wrote: > > On Wed, 2011-02-16 at 02:12 -0800, Daniel Roseman wrote: > > Your question betrays a misconception that I often see. Django - at > > least > > when served other than via CGI - does not reload everything for each > > request. The Django process is long-running, and is managed by the > > server, > > but usually runs for a number of requests before being respawned. > > could you elaborate on this? I am suffering from this misconception. > Not sure what else to say. Taking mod_wsgi as an example, Apache spawns a number of processes and/or threads to serve Django requests, depending on your mod_wsgi settings. Each of these is long-running, in the sense that they are not tied to a specific request/response cycle - again, depending on your configuration, they can either persist indefinitely (until Apache itself is restarted), or for a specified number of requests. So anything that's imported, or set as a variable in the global or module-level context, will also persist for multiple requests.
This is why you often see issues where people set the default for a field, for example, to datetime.datetime.now(), and then get the exact same default for all items until the server is restarted: because that function is evaluated when the class is defined, and the value persists until the process is killed. (The solution, of course, is to use the callable itself without calling it: datetime.datetime.now.) And it's also why the developers of the new class-based views functionality in 1.3 had such trouble and went to such great lengths to avoid data leaking from one request to the next. -- DR. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. 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.
