tags:

views:

230

answers:

3

Is it somehow possible to access the request object inside settings.py? Maybe by creating a temporary settings object, modifying it and then telling the rest of the "chain" to use that instead of the normal settings.py?

I need it to decide which DB-connection to use.

As an extra question. If I were to have something like 5000 database connections, would settings.py be just as efficient as storing them in a sqlite db on the web-frontend? And would it be just as painless to update the connections? Or does the server have to be reloaded to catch the changes in settings.py?

Edit: To clarify why I might be needing that many connections. I am building a webapp. It's SaaS and like many others the accounts will each have a subdomain that they can create users on and will have no need to interact with any other subdomain/account. It would then be nice to confine each account to a DB all of its own. This grants some extra security and simplifies the app. There are many more advantages to it, but this should illustrate it just fine. This is why I might end up with that many different databases (but not that many different physical servers if that makes any difference).

A: 

Django's ORM is not designed to switch database credentials mid-stride. Perhaps you would be happier with something a bit more DIY, such as SQLAlchemy.

Ignacio Vazquez-Abrams
Yes I have thought about SQLAlchemy, but I hope to keep it as close to "normal" Django as possible.Django can now use multiple databases. It is in the trunk 1.2. And the docs detail it here: http://docs.djangoproject.com/en/dev/topics/db/multi-db/I could just do something on the query-side of things to select the right database with objects.using, but I would rather have it in the settings since it makes the app easier to move to a local install where it will only ever have one database and no subdomain.
Mathias Nielsen
A: 

If i understand this right, you could use django's new db-routing system and select database on-the-fly based on model instance (e.g. your user) without the need of using() call.

Dmitry Shevchenko
That might work, but I also need to redirect auth to the same DB based on subdomain since the users for that account is also stored in its DB.But what about db calls not including a auth.user instance? I am not sure I understand it correctly, but isn't the only instance the one currently being queried?
Mathias Nielsen
hm, true, that could be a problem
Dmitry Shevchenko
A: 

I've addressed this problem on a site I've been using recently, and decided to let Apache/mod_wsgi do the work. This solution adds a bit of memory and CPU overhead, but for my app it was the best way to keep everything flexible.

Apache .conf:

SetEnv DJANGO_TEMPLATE_DIR '/usr/local/www/apache22/data/django/templates/'
<VirtualHost *:80>
    ServerName encendio.whatever.com
    ServerAdmin [email protected]
    DocumentRoot "/usr/local/www/apache22/data"
    SetEnv DJANGO_DATABASE_NAME monkeys
    SetEnv DJANGO_DATABASE_USER root
    SetEnv DJANGO_DATABASE_PASSWORD secretPass
    SetEnv DJANGO_DATABASE_PORT ''
    SetEnv DJANGO_DATABASE_HOST ''
    WSGIScriptAlias / /usr/local/www/apache22/data/django/wsgi_handler.py
</VirtualHost>

settings.py:

DATABASE_NAME =     os.environ.get('DJANGO_DATABASE_NAME', '')
DATABASE_USER =     os.environ.get('DJANGO_DATABASE_USER', '')
DATABASE_PASSWORD = os.environ.get('DJANGO_DATABASE_PASSWORD', '')
DATABASE_HOST =     os.environ.get('DJANGO_DATABASE_HOST', '')

This allows you to set up each site as a VirtualHost in the httpd.conf.

Jack M.
This could be a step in the right direction. But defining all the subdomains on all the front-end servers might become a maintenance nightmare.Wonder if it is possible to define a *.whatever.com VH and then pass the first part of the URL and pass it to SetEnv... Gotta go find out. Thanks for the tip
Mathias Nielsen
That shouldn't work. When using mod_wsgi variables set by SetEnv are not put into the process environment variables by mod_wsgi, nor are they put into os.environ by the Django WSGI adapter. It is also not recommended that you use such a practice as would not be multithread safe if variables could be different on a per request basis.
Graham Dumpleton