Django は既存のデータベースとアプリケーションを統合します

Django は、いわゆる緑地開発に最適です。これは、緑の芝生が広がる未耕作の土地に建物を一から建てるのと同じように、ゼロからプロジェクトを構築することです。ただし、Django はゼロからのプロジェクトを好むにもかかわらず、フレームワークを以前のレガシー データベースやアプリケーションと統合することは可能です。この章では、いくつかの統合テクニックを紹介します。

レガシー データベースとの統合

Django のデータベース層は Python コードから SQL
スキーマを生成します。ただし、レガシー データベースの場合、すでに SQL スキーマがあり、その場合は既存のデータベース テーブルのモデルを記述する必要があります (Forパフォーマンス上の理由から、Django のデータベース層は、データベースのランタイム イントロスペクションによるオブジェクト リレーショナル マッピングをサポートしていません (これは機能しません (データベース API を使用するには、モデル コードを記述する必要があります)。幸いなことに、Django には計画が付属しています)。データベース テーブルを読み取ることで、モデル コードを生成する補助ツールです。補助ツールは、manage.py
inspectdb と呼ばれます

inspectdb を使用します

inspectdb ツールは、構成ファイル (設定ファイル) が指すデータベースを内向きにチェックします。 Django
モデルのパフォーマンスをテーブルごとに生成し、これらの Python モデルのコードをシステムの標準出力に表示します。

以下は、一般的なレガシー データベースを最初から統合するプロセスです

django-admin.py startproject mysite (mysite はプロジェクトの名前です) を実行して、Django プロジェクトをセットアップします。この例では、プロジェクトの名前として mysite を使用しましょう。

プロジェクト内の構成ファイル
mysite/settings.py を編集し、データベース接続パラメーターとデータベース名を Django に伝えます。具体的には、DATABASE_NAME、DATABASE_ENGINE、DATABASE_USER、DATABASE_PASSWORD、DATABASE_HOST、DATABASE_PORT を指定します。 pythonmysite/manage.pystartappmyapp を実行して Django アプリケーションを作成します (myapp はアプリケーションの名前です)。このアプリケーションの名前として myapp を使用します

コマンド pythonmysite/manage.pyinspectdb を実行します。これにより、DATABASE_NAME データベース内のすべてのテーブルがチェックされ、各テーブルに対して生成されたモデル

クラスが出力されます。出力して、inspectdb で何ができるかを考えてください。

標準シェルの出力をリダイレクトし、その出力をアプリケーションの models.py ファイルに保存します。

python mysite/manage.py Inspectiondb > models.py

mysite/myapp/models.py ファイルを編集して、生成されたモデルをクリーンアップし、必要なカスタマイズを行います。次の章には、これに関する良いアドバイスがいくつかあります。

生成されたモデルをクリーンアップする

ご想像のとおり、データベースのイントロスペクションは完璧ではないため、生成されたモデル コードに対してクリーンアップを行う必要があります。生成されたモデルの処理に関する重要なポイントについての注意事項は次のとおりです:

データベース内のすべてのテーブルはモデル クラスに変換されます (つまり、データベース テーブルとモデルの間には 1 対 1 のマッピングが存在します)クラス）。これは、モデルが多対多結合用のManyToManyField オブジェクトであるテーブルをリファクタリングする必要があることを意味します。

生成された各モデルの各フィールドには、id 主キー フィールドを含む独自の属性があります。ただし、モデルに主キーがない場合、Django はモデルに ID 主キー フィールドを自動的に追加することに注意してください。この場合、次のコードを使用して任意の行に対して削除操作を実行するとよいでしょう:

id = models.IntegerField(primary_key=True)

これは、これらの行が冗長であるためだけでなく、これらの行は、アプリケーションがこれらのテーブルに新しいレコードを追加する必要がある場合に問題を引き起こす可能性があります。 Inspectiondb コマンドは、フィールドが自動増加しているかどうかを検出できないため、必要に応じてフィールドを AutoField に変更する必要があります。

CharField、DateField などの各フィールド タイプは、VARCHAR などのデータベース列タイプを検索することによって決定されます。 、DATEによって決定されます。 Inspectiondb がデータベースの列タイプに従ってモデル フィールド タイプをマッピングできない場合、代わりに TextField フィールドが使用され、生成されたモデル フィールドの後に「フィールド タイプは推測されています」という Python コメントが追加されます。したがって、これに特に注意し、必要に応じてこれらのフィールド タイプを変更してください。

データベース内のフィールドに Django で対応する適切なフィールドが見つからない場合は、Django レイヤーではテーブル内のすべてのフィールドを含める必要がないため、安全にスキップできます。

データベース内の列の名前が pass、class、for などの Python の予約語である場合、inspectdb は各属性名の後に _field を追加し、db_column 属性を実際のフィールド名に設定します。パス、クラスまたは for など。

たとえば、テーブルに列名が for の INT 型の列が含まれている場合、生成されるモデルには次のようなフィールドが含まれます:

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

Inspectiondb は、フィールドの後に「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认证系统能让您以插件方式与其他认证资源进行交互。您可以覆盖Diangos的默认基于数据库模式，您还可以使用默认的系统与其他系统进行交互。

指定认证后台

在后台，Django维护了一个用于检查认证的后台列表。当某个人调用django.contrib.auth.authenticate()(如12章中所述)时，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。

如Django会话、用户和注册中所述，Django管理系统紧密连接于其自己后台数据库的User对象。实现这个功能的最好办法就是为您的后台数据库（如LDAP目录，外部SQL数据库等）中的每个用户都创建一个对应的Django
User对象。您可以提前写一个脚本来完成这个工作，也可以在某个用户第一次登陆的时候在authenticate方法中进行实现。

以下是一个示例后台程序，该后台用于认证定义在setting.py文件中的username和password变量，并且在该用户第一次认证的时候创建一个相应的DjangoUser对象。

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和遗留Web应用集成

同由其他技术驱动的应用一样，在相同的Web服务器上运行Django应用也是可行的。最简单直接的办法就是利用Apaches配置文件httpd.conf，将不同的URL类型代理至不同的技术。

关键在于只有在您的httpd.conf文件中进行了相关定义，Django对某个特定的URL类型的驱动才会被激活。在第20章中解释的缺省部署方案假定您需要Django去驱动某个特定域上的每一个页面。

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

这里, a18e6dc59b27f1dbd64eaa88f15b0c14这一行表示用Django处理每个以根开头的URL.

精妙之处在于Django将9d68f4d645dd62cd4e002580b75a8b85指令值限定于一个特定的目录树上。举个例子，比如说您有一个在某个域中驱动大多数页面的遗留PHP应用，并且您希望不中断PHP代码的运行而在../admin/位置安装一个Django域。要做到这一点，您只需将9d68f4d645dd62cd4e002580b75a8b85值设置为/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/），而非去掉/admin/后的那部分URL（例如``/people/person/add/）。这意味着您的根URLconf必须包含居前的/admin/。

以上就是Django集成已有的数据库和应用的内容，更多相关内容请关注PHP中文网（www.php.cn）！