2011-07-21 48 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