在一台服务器上，如何在Django上设置多个帐号？ [英] How does one set up multiple accounts with separate databases for Django on one server?
问题描述
安装Django有哪些选项可以让多个用户（每个都有Account）都可以拥有自己的数据库？
语义相当直观。帐户可能有多个用户。帐户具有唯一的数据库（数据库对应于一个帐户）。图片WordpressMU。 ：）
我已经考虑过：
-
外部解决方案 - 多路复用到多个服务器/守护程序
多个Django安装，每个Django安装/项目对应于设置自己的DATABASE_NAME的帐户，例如
文件系统：
/ bob
/ settings .py（包含DATABASE_NAME =bob）
/ sue
/settings.py（包含DATABASE_NAME =sue）
然后为每个bob和sue运行一个Django实例。我不喜欢这种方法 - 感觉很残酷，闻起来很臭。但是我相信它会奏效，并根据建议，这可能是最干净，最聪明的方式。
应用程序可以存储在其他地方;唯一需要django配置唯一的是settings.py（甚至只有DATABASE_NAME等需要不同，其余的可以导入）。
（顺便说一下，我使用的是lighttpd和FastCGI。）
-
内部解决方案 - Django多路复用数据库设置
另一方面，我想到有一个单一的Django安装，
（a）添加一个prefix_ 到每个数据库表，对应于登录用户的帐户;或
（b）根据登录用户的帐户更改数据库。
I特别感兴趣的是看到Django方式来做这些事情（希望这是一个简单的事情）。例如，中间件需要一个请求的用户，并将django.conf.SETTINGS ['DATABASE_NAME']更改为该用户帐户的数据库。
这会引发红旗，即这个线程安全吗？即更改django.conf.SETTINGS会影响其他进程吗？更改django.conf.SETTINGS是否存在固有的危险 - DB连接是否已经安装？是否重新启动数据库连接部分的公共API？ - 当我再次看到这个问题时，我将看看Django的源码。
我意识到2（a）和（b）可能需要以不同的机制存储和访问用户身份验证核心。
现在，我在网络服务器层的外部映射上去 - 它现在是最简单和最干净的。但是，我不喜欢每个帐户运行FastCGI守护程序的想法 - 似乎不必要地浪费记忆，特别是如果有2000多个帐户。然而，我想保持这个讨论是开放的，因为这是一个有趣的问题，解决方案似乎不适合某些情况。
评论正式赞赏。
干杯
Django方式一定是使用自己的数据库名称（＃1）进行单独安装。 ＃2会涉及到ORM的一些黑客入侵，即使这样我也不太确定这是可能的。
但是，请记住，你不要需要一个全新的安装所有网站的模型/视图/模板为每个用户，只需一个新的settings.py与通用源文件的所有相应的路径。另外，要在Apache中运行所有这些安装，请按照我在这里的方式进行操作：
< VirtualHost 1.2.3.4>
DocumentRoot / www / site1
ServerName site1.com
<位置/>
SetHandler python程序
SetEnv DJANGO_SETTINGS_MODULE site1.settings
PythonPath['/ www'] + sys.path
PythonDebug On
PythonInterpreter site1
< /地点>
< / VirtualHost>
< VirtualHost 1.2.3.4>
DocumentRoot / www / site2
ServerName site2.com
<位置/>
SetHandler python程序
SetEnv DJANGO_SETTINGS_MODULE site2.settings
PythonPath['/ www'] + sys.path
PythonDebug On
PythonInterpreter site2
< /地点>
< / VirtualHost>
假设你有/www/site1/settings.py，www / site2 / settings.py等等...
当然，你现在需要一个主要的网站，人们登录，然后重定向到相应的网站（这里我有只是把它当作site1.com，site2.com，但你会得到想法。）
What options are there for installing Django such that multiple users (each with an "Account") can each have their own database?
The semantics are fairly intuitive. There may be more than one User for an Account. An Account has a unique database (and a database corresponds to an account). Picture WordpressMU. :)
I've considered this:
External solution - Multiplex to multiple servers/daemons
Multiple Django installations, with each Django installation / project corresponding to an account that sets its own DATABASE_NAME, e.g.
File system:
/bob /settings.py (contains DATABASE_NAME="bob") /sue /settings.py (contains DATABASE_NAME="sue")Then having a Django instance running for each of bob and sue. I don't like this methodology- it feels brutish and it smells foul. But I'm confident it would work, and based on the suggestions it might be the cleanest, smartest way to do it.
The apps can be stored elsewhere; the only thing that need be unique to the django configuration is the settings.py (and even there, only DATABASE_NAME, etc. need be different, the rest can be imported).
(Incidentally, I'm using lighttpd and FastCGI.)
Internal solution - Django multiplexing database settings
On the other hand, I've thought of having one single Django installation, and
(a) Adding a "prefix_" to each database table, corresponding to account of the logged-in user; or
(b) Changing the database according to the account of the User that is logged in.
I'd be particularly interested in seeing the "Django way" to do these (hoping that it's something dead-simple). For example, middleware that takes a Request's User and changes the django.conf.SETTINGS['DATABASE_NAME'] to the database for this user's account.
This raises red flags, viz. Is this thread-safe? i.e. Does changing django.conf.SETTINGS affect other processes? Is there just an inherent danger in changing django.conf.SETTINGS -- would the DB connection be setup already? Is restarting the DB connection part of the public API? -- I'm going to have a look at the Django source when I look to this problem again.
I'm conscious that 2(a) and (b) could require User authentication to be stored and accessed in a different mechanism that the core.
For now, I'm going to go with the external mapping at the webserver layer- it's simplest and cleanest for now. However, I don't like the idea of FastCGI daemons running for every account- it seems to needlessly waste memory, particularly if there will be 2000+ accounts. However, I'd like to keep this discussion open as it's an interesting problem and the solution doesn't seem ideal for certain cases.
Comments duly appreciated. Cheers
The Django way would definitely be to have separate installations with their own database name (#1). #2 would involve quite a bit of hacking with the ORM, and even then I'm not quite sure it's possible at all.
But mind you, you don't need a WHOLE new installation of all the site's models/views/templates for each user, just a new settings.py with all the appropriate paths to the common source files. Plus, to run all these installations in Apache, do it the way I do here:
<VirtualHost 1.2.3.4>
DocumentRoot /www/site1
ServerName site1.com
<Location />
SetHandler python-program
SetEnv DJANGO_SETTINGS_MODULE site1.settings
PythonPath "['/www'] + sys.path"
PythonDebug On
PythonInterpreter site1
</Location>
</VirtualHost>
<VirtualHost 1.2.3.4>
DocumentRoot /www/site2
ServerName site2.com
<Location />
SetHandler python-program
SetEnv DJANGO_SETTINGS_MODULE site2.settings
PythonPath "['/www'] + sys.path"
PythonDebug On
PythonInterpreter site2
</Location>
</VirtualHost>
assuming you've got /www/site1/settings.py, www/site2/settings.py and so on...
Of course, you now need to have a main site where people log in, that then redirects you to the appropriate site (here I've just put it as "site1.com", "site2.com", but you get the idea.)
这篇关于在一台服务器上，如何在Django上设置多个帐号？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
