Django最適合于所謂的green-field開發，即從頭開始的一個項目，正如你在一塊還長著青草的未開墾的土地上從零開始建造一棟建筑一般。 然而，盡管Django偏愛從頭開始的項目，將這個框架和以前遺留的數據庫和應用相整合仍然是可能的。 本章就將介紹一些整合的技巧。 ## 與遺留數據庫整合 Django的數據庫層從Python代碼生成SQL schemas—但是對于遺留數據庫，你已經擁有SQL schemas. 這種情況,你需要為已經存在的數據表創建model. 為此,Django自帶了一個可以通過讀取您的數據表結構來生成model的工具. 該輔助工具稱為inspectdb,你可以通過執行`manage.py?inspectdb`來調用它. ### 使用?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章) > > 通過運行?python?mysite/manage.py?startapp?myapp?(這里?myapp?是你的應用的名字)創建一個Django應用。 這里我們使用myapp?做為應用名。 > > 運行命令?python?mysite/manage.py?inspectdb。這將檢查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將指令值限定于一個特定的目錄樹上。 舉個例子，比如說您有一個在某個域中驅動大多數頁面的遺留PHP應用，并且您希望不中斷PHP代碼的運行而在../admin/位置安裝一個Django域。 要做到這一點，您只需將值設置為/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/`?。 ## 下一章 如果你的母語是英語, 你可能就不會注意到許多Django admin網站中最酷的特性功能。 它支持超過50種語言! Django 的國際化框架使其成為可能( 還有Django志愿翻譯者的努力 ) 下一章介紹如何使用這個框架來提供本地化的Django網站。