2011-07-21 46 views
1

我正在构建一个集中的django应用程序,它将与具有基本相同模式的动态数量的数据库进行交互。这些数据库也被一些遗留应用程序使用,其中一些应用程序使用PHP。我们的解决方案避免了多个数据库证书孤岛,它将这些信息存储在各个应用程序之外的通用设置文件中。设置文件可以创建,更改或删除,而不必重新启动django应用程序。Django中动态的每个请求数据库连接

对于每个向django应用程序发出的请求,都会有一个http头或一个url参数,它可以用来推断要查看哪个设置文件来确定要使用哪个数据库凭证。

我的第一个想法是使用自定义django中间件来解析设置文件(可能使用缓存),并在每个请求上创建一个新的连接对象,并在任何ORM活动之前将其修补为django.db。

有没有更优雅的方法来处理这种情况?有什么线程安全问题,我应该考虑与中间件方法?

回答

2

重新读取文件是一个沉重的代价,当文件不太可能发生变化时要付出代价。

我通常的做法是使用INotify监视配置文件的更改,而不是尝试读取每个请求上的文件。此外,我倾向于保留一个“当前”配置,从文件中解析出来,并且只有在完成解析配置文件后我才用新值替换它,并且我确定它是有效的。您可以通过在每个传入请求上设置当前配置来解决您对线程安全性的一些担忧,以便配置不会在请求中途改变。

+0

我不在乎解析问题的成本,所以我提到了缓存。如果推导出的数据库名称尚不存在,只需在settings.DATABASES中添加更多条目并刷新数据库连接错误就相当简单。更大的问题是中间件方法是否正确,或者在请求/响应周期中是否太迟或者是否存在线程安全问题。 – GDorn

+0

哦..不,中间件似乎是一个很好的选择。 – SingleNegationElimination

0

您可以在不同的端口上启动不同的settings.py文件(通过设置不同的DJANGO_SETTINGS_MODULE),并将请求重定向到特定的应用程序。只是我2美分。

+0

由于涉及到的开销很大,因此在实例数量和所需的系统级配置量方面,这不是一个真正的选项。 – GDorn