第十八章： 集成已有的數據庫和應用

第十八章： 集成已有的數據庫和應用

Django最適合於所謂的green-field開發，即從頭開始的一個項目，正如你在一塊還長着青草 的未開墾的土地上從零開始建造一棟建築通常。 然而，儘管Django偏心從頭開始的項目，將這個框架和之前遺留的數據庫和應用相整合仍然是可能的。 本章就將介紹一些整合的技巧。

與遺留數據庫整合

Django的數據庫層從Python代碼生成SQL schemas—可是對於遺留數據庫，你已經擁有SQL schemas. 這種狀況,你須要爲已經存在的數據表建立model. 爲此,Django自帶了一個能夠經過讀取您的數據表結構來生成model的工具. 該輔助工具稱爲inspectdb,你能夠經過執行manage.pyinspectdb來調用它.

使用 inspectdb

inspectdb工具自省你配置文件指向的數據庫，針對每個表生成一個Django模型，而後將這些Python模型的代碼顯示在系統的標準輸出裏面。

下面是一個從頭開始的針對一個典型的遺留數據庫的整合過程。 兩個前提條件是安裝了Django和一個傳統數據庫。

經過運行django-admin.py startproject mysite (這裏 mysite 是你的項目的名字)創建一個Django項目。 好的，那咱們在這個例子中就用這個 mysite 做爲項目的名字。

編輯項目中的配置文件, mysite/settings.py ,告訴Django你的數據庫鏈接參數和數據庫名。 具體的說，要提供 DATABASE_NAME , DATABASE_ENGINE , DATABASE_USER , DATABASE_PASSWORD , DATABASE_HOST , 和 DATABASE_PORT 這些配置信息.。 (請注意其中的一些設置是可選的。 更多信息參見第5章)

經過運行 pythonmysite/manage.pystartappmyapp (這裏 myapp 是你的應用的名字)建立一個Django應用。 這裏咱們使用myapp 作爲應用名。

運行命令 pythonmysite/manage.pyinspectdb。這將檢查DATABASE_NAME 數據庫中全部的表並打印出爲每張表生成的模型類。 看一看輸出結果以瞭解inspectdb能作些什麼。

將標準shell的輸出重定向，保存輸出到你的應用的 models.py 文件裏：

python mysite/manage.py inspectdb > mysite/myapp/models.py

編輯 mysite/myapp/models.py 文件以清理生成的 models 而且作一些必要的自定義。 針對這個，下一個節有些好的建議。

清理生成的Models

如你可能會預料到的，數據庫自省不是完美的，你須要對產生的模型代碼作些許清理。 這裏提醒一點關於處理生成 models 的要點:

數據庫的每個表都會被轉化爲一個model類 (也就是說，數據庫的表和model 類之間是一對一的映射)。 這意味着你須要爲多對多鏈接的表，重構其models 爲 ManyToManyField 的對象。

所生成的每個model中的每一個字段都擁有本身的屬性，包括id主鍵字段。 可是，請注意，若是某個model沒有主鍵的話，那麼Django會自動爲其增長一個id主鍵字段。 這樣一來，你也許但願移除這樣的代碼行。

id = models.IntegerField(primary_key=True)

這樣作並非僅僅由於這些行是冗餘的，並且若是當你的應用須要向這些表中增長新記錄時，這些行會致使某些問題。

每個字段類型，如CharField、DateField， 是經過查找數據庫列類型如VARCHAR,DATE來肯定的。若是inspectdb沒法把某個數據庫字段映射到model字段上，它會使用 TextField字段進行代替，而且會在所生成model字段後面加入Python註釋「該字段類型是猜的」。 對這要小心，若是必要的話，更改字段類型。

若是你的數據庫中的某個字段在Django中找不到合適的對應物，你能夠放心的略過它。 Django模型層不要求必須導入你數據庫表中的每一個列。

若是數據庫中某個列的名字是Python的保留字（好比pass、class或者for等），inspectdb會在每一個屬性名後附加上_field，並將db_column屬性設置爲真實的字段名（也就是pass,class或者for等）。

例如，某張表中包含一個INT類型的列，其列名爲for，那麼所生成的model將會包含以下所示的一個字段：

for_field = models.IntegerField(db_column='for')

inspectdb 會在該字段後加注 ‘字段重命名，由於它是一個Python保留字’ 。

若是數據庫中某張表引用了其餘表（正如大多數數據庫系統所作的那樣），你須要適當的修改所生成 model的順序，以使得這種引用可以正確映射。 例如，model Book擁有一個針對於model Author的外鍵，那麼後者應該先於前者被定義。若是你想建立一個指向還沒有定義的model的關係，那麼可使用包含model名的字符串，而不是 model對象自己。

對於PostgreSQL,MySQL和SQLite數據庫系統，inspectdb可以自動檢測出主 鍵關係。 也就是說，它會在合適的位置插入primary_key=True。 而對於其餘數據庫系統，你必須爲每個model中至少一個字段插入這樣的語句，由於Django的model要求必須擁有一個 primary_key=True的字段。

外鍵檢測僅對PostgreSQL，還有MySQL表中的某些特定類型生效。 至於其餘數據庫，外鍵字段將在假定其爲INT列的狀況下被自動生成爲IntegerField。

與認證系統的整合

將Django與其餘現有認證系統的用戶名和密碼或者認證方法進行整合是能夠辦到的。

例如，你所在的公司也許已經安裝了LDAP，而且爲每個員工都存儲了相應的用戶名和密碼。 若是用戶在LDAP和基於Django的應用上擁有獨立的帳號，那麼這時不管對於網絡管理員仍是用戶本身來講，都是一件很使人頭痛的事兒。

爲了解決這樣的問題，Django認證系統能讓您以插件方式與其餘認證資源進行交互。 您能夠覆蓋Diango默認的基於數據庫的模式，您還可使用默認的系統與其餘系統進行交互。

指定認證後臺

在後臺，Django維護了一個用於檢查認證的後臺列表。 當某我的調用 django.contrib.auth.authenticate() (如14章中所述)時，Django會嘗試對其認證後臺進行遍歷認證。 若是第一個認證方法失敗，Django會嘗試認證第二個，以此類推，一直到嘗試完。

認證後臺列表在AUTHENTICATION_BACKENDS設置中進行指定。 它應該是指向知道如何認證的Python類的Python路徑的名字數組。 這些類能夠在你Python路徑的任何位置。

默認狀況下，AUTHENTICATION_BACKENDS被設置爲以下：

('django.contrib.auth.backends.ModelBackend',)

那就是檢測Django用戶數據庫的基本認證模式。

AUTHENTICATION_BACKENDS的順序很重要，若是用戶名和密碼在多個後臺中都是有效的，那麼Django將會在第一個正確匹配後中止進一步的處理。

編寫認證後臺

一個認證後臺其實就是一個實現了以下兩個方法的類： get_user(id) 和 authenticate(**credentials) 。

方法 get_user 須要一個參數 id ，這個 id 能夠是用戶名，數據庫ID或者其餘任何數值，該方法會返回一個 User 對象。

方法 authenticate 使用證書做爲關鍵參數。 大多數狀況下，該方法看起來以下：

class MyBackend(object):
    def authenticate(self, username=None, password=None):
        # Check the username/password and return a User.

可是有時候它也能夠認證某個短語，例如：

class MyBackend(object):
    def authenticate(self, token=None):
        # Check the token and return a User.

每個方法中， authenticate 都應該檢測它所獲取的證書，而且當證書有效時，返回一個匹配於該證書的 User 對象，若是證書無效那麼返回 None 。 若是它們不合法，就返回None。

如14章中所述，Django管理系統緊密鏈接於其本身後臺數據庫的 User 對象。 實現這個功能的最好辦法就是爲您的後臺數據庫（如LDAP目錄，外部SQL數據庫等）中的每一個用戶都建立一個對應的Django User對象。 您能夠提早寫一個腳原本完成這個工做，也能夠在某個用戶第一次登錄的時候在 authenticate 方法中進行實現。

如下是一個示例後臺程序，該後臺用於認證定義在 setting.py 文件中的username和password變量，而且在該用戶第一次認證的時候建立一個相應的Django User 對象。

from django.conf import settings
from django.contrib.auth.models import User, check_password

class SettingsBackend(object):
    """
    Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.

    Use the login name, and a hash of the password. For example:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'sha1$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de'
    """
    def authenticate(self, username=None, password=None):
        login_valid = (settings.ADMIN_LOGIN == username)
        pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
        if login_valid and pwd_valid:
            try:
                user = User.objects.get(username=username)
            except User.DoesNotExist:
                # Create a new user. Note that we can set password
                # to anything, because it won't be checked; the password
                # from settings.py will.
                user = User(username=username, password='get from settings.py')
                user.is_staff = True
                user.is_superuser = True
                user.save()
            return user
        return None

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

更多認證模塊的後臺, 參考Django文檔。

和遺留Web應用集成

同由其餘技術驅動的應用同樣，在相同的Web服務器上運行Django應用也是可行的。 最簡單直接的辦法就是利用Apaches配置文件httpd.conf，將不一樣的URL類型分發至不一樣的技術。 （請注意，第12章包含了在Apache/mod_python上配置Django的相關內容，所以在嘗試本章集成以前花些時間去仔細閱讀第12章或許是 值得的。)

關鍵在於只有在您的httpd.conf文件中進行了相關定義，Django對某個特定的URL類型的驅動纔會被激活。 在第12章中解釋的缺省部署方案假定您須要Django去驅動某個特定域上的每個頁面。

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

這裏, <Location"/"> 這一行表示用Django處理每一個以根開頭的URL.

精妙之處在於Django將<location>指令值限定於一個特定的目錄樹上。 舉個例子，好比說您有一個在某個域中驅動大多數頁面的遺留PHP應用，而且您但願不中斷PHP代碼的運行而在../admin/位置安裝一個Django 域。 要作到這一點，您只需將<location>值設置爲/admin/便可。

<Location "/admin/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>

有了這樣的設置，只有那些以/admin/開頭的URL地址纔會觸發Django去進行處理。 其餘頁面會使用已存在的設置。

請注意，把Diango綁定到的合格的URL（好比在本章例子中的 /admin/ ）並不會影響其對URL的解析。 絕對路徑對Django纔是有效的（例如 /admin/people/person/add/ ），而非截斷後的URL（例如 /people/person/add/ ）。這意味着你的根URLconf必須包含前綴 /admin/ 。