My goal is to eventually be able to run multiple Django projects in the same WSGI server instance. I believe that translates into Django being loaded at the process level but the Django projects (i.e. the requests for a project) being run at the thread level.
My lack of experience in Python is going to become apparent really quick, so I hope you will be forgiving. I managed to make a small change in the Django source when running Django with a WSGI handler that allowed me to switch the configuration module per-request. While it worked with respect to getting the settings to be picked up per- request, it seemed to introduce some other problems. You can take a look at the sources I was using by by downloading: http://groups.google.com/group/pyisapie/web/multiple_django.zip and then: 1) run `python wsgi_server.py` (which maps a URL to a Django project, assigns the DJANGO_SETTINGS_MODULE variable accordingly, and the starts the Django WSGI Handler) You should now be able to browse to: 1) http://localhost:8000/dgtutorial/polls.py 2) http://localhost:8000/dgtutorial2/polls.py Notice that the second request fails because it is running off dgtutorial's settings module (and not dgtutorial2's settings module). This is because Django only picks up the settings module once (i.e. per python process load), not on each request. Now, apply the patch included in the zip file above. It forces the settings module to be reassigned on every WSGI request instead of on a per-process initialization (in django.conf.__init__.py). This accomplishes the short-term goal of getting the settings modules assigned according to the request. You should now be able to browse again to: 1) http://localhost:8000/dgtutorial/polls.py 2) http://localhost:8000/dgtutorial2/polls.py The output tells us two things: 1) The appropriate settings modules for the different projects are being assigned to Django based on the URL requested. 2) Django is relying on a process-level (not thread level) configuration value somewhere which is causing our static template output to be cached and used from the wrong project (that is why you see "project (static value): dgtutorial" at the top of the output for dgtutorial2"). If you stop the server (CTRL+BREAK) and restart it and browse to the second url first and then the first, it proves the output has been cached somehow. So, this leads me to the following *unsubstantiated* conclusion: that there are numerous places where the Django core is assuming that only one project will be run concurrently in each process and there are a lot of settings and values stored at the process level instead of the thread level. I began to hunt for those instances when it dawned on me that the above patch was probably not thread safe. Rather than storing the settings in django.conf.settings, they probably need to be stored in some kind of per-thread scoped variable. Unfortunately, I am now completely out of my area of expertise and would appreciate some comments from others who have more experience in this area. Thoughts, comments, critiques (not flames) welcome. :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
