Django intègre les bases de données et applications existantes

Django est le mieux adapté au développement dit « green-field », qui est un projet à partir de zéro, tout comme vous construirez un bâtiment à partir de zéro sur un terrain inculte où l'herbe pousse encore. Cependant, malgré la préférence de Django pour les projets à partir de zéro, il est toujours possible d'intégrer le framework aux bases de données et applications existantes. Ce chapitre présentera quelques techniques d'intégration.

Intégration avec les bases de données existantes

La couche de base de données de Django génère des
schémas SQL à partir du code Python — mais avec les bases de données existantes, vous disposez déjà de schémas SQL, ce qui est le cas Ensuite, vous devez écrire un modèle pour votre table de base de données existante (pour des raisons de performances, la couche de base de données de Django ne prend pas en charge le mappage objet-relationnel non fonctionnel via l'introspection d'exécution de la base de données, afin d'utiliser l'API de base de données, vous devez écrire le modèle code), Heureusement, Django est livré avec un outil d'aide qui génère du code de modèle en lisant le plan de table de votre base de données. Cet outil d'aide s'appelle manage.py
inspectdb

Utilisation d'inspectdb

L'outil inspectdb vérifie de manière introspective la base de données pointée par votre fichier de configuration (fichier de configuration), génère une représentation de modèle Django

pour chacune de vos tables, puis affiche le code de ces modèles Python dans la sortie standard de le système dans.

Ce qui suit est un processus d'intégration pour une base de données héritée typique à partir de zéro

En exécutant django-admin .py startproject mysite (où mysite est le nom de votre projet) crée un projet Django. D'accord, utilisons monsite comme nom du projet dans cet exemple.

Modifiez le fichier de configuration dans le projet,

mysite/settings.py, et indiquez à Django vos paramètres de connexion à la base de données et le nom de la base de données. Plus précisément, fournissez les informations de configuration DATABASE_NAME, DATABASE_ENGINE, DATABASE_USER, DATABASE_PASSWORD, DATABASE_HOST et DATABASE_PORT

En exécutant pythonmysite/manage.pystartappmyapp (où myapp est le nom de votre application) pour. créez une application Django. Ensuite, nous utilisons myapp comme nom de l'application

Exécutez la commande pythonmysite/manage.pyinspectdb Ce sera dans la base de données DATABASE_NAME Vérifiez tout. tables et imprimez la classe de modèle

générée pour chaque table. Jetez un œil à la sortie et réfléchissez à ce que inspectdb peut faire.

Modifiez la norme Redirigez la sortie. du shell et enregistrez la sortie dans le fichier models.py de votre application :

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

Edit mysite/ myapp/ models.py pour nettoyer les modèles générés et effectuer les personnalisations nécessaires. Le chapitre suivant contient de bons conseils à ce sujet.

Nettoyer les modèles générés

Comme vous vous en doutez, l'introspection de la base de données n'est pas parfaite et vous devrez effectuer un nettoyage sur le code du modèle généré. Voici quelques points importants concernant le traitement des modèles générés :

Chaque table de la base de données sera convertie en une classe de modèle (c'est-à-dire la table de la base de données et la classe du modèle) une cartographie un-à-un entre eux). Cela signifie que vous devez refactoriser les tables dont les modèles sont des objets ManyToManyField pour les jointures plusieurs-à-plusieurs.

Chaque champ de chaque modèle généré a ses propres attributs, y compris le champ de clé primaire id. Notez cependant que si un modèle ne possède pas de clé primaire, Django y ajoutera automatiquement un champ de clé primaire Id. Dans ce cas, vous souhaiterez peut-être utiliser le code suivant pour effectuer l'opération de suppression sur n'importe quelle ligne :

id = models.IntegerField(primary_key=True)

Cela n'est pas fait simplement parce que le les lignes sont redondantes. Ces lignes peuvent poser des problèmes si votre application doit ajouter de nouveaux enregistrements à ces tables. La commande inspectdb ne peut pas détecter si un champ augmente automatiquement, donc si nécessaire, vous devez le modifier en AutoField.

Chaque type de champ, tel que CharField, DateField est déterminé en recherchant des types de colonnes de base de données tels que VARCHAR et DATE. Si inspectdb ne peut pas mapper un type de champ de modèle en fonction du type de colonne de base de données, il utilisera à la place le champ TextField et ajoutera un commentaire Python "Le type de champ est deviné" après le champ de modèle généré. Par conséquent, veuillez y prêter une attention particulière et modifier ces types de champs en conséquence si nécessaire.

Si un champ de votre base de données ne trouve pas de contrepartie appropriée dans Django, vous pouvez l'ignorer en toute sécurité car la couche Django ne l'exige pas. Incluez tous les champs dans votre table.

Si le nom d'une colonne dans la base de données est un mot réservé de Python, tel que pass, class ou for, etc., inspectdb ajoutera _field après chaque nom d'attribut . Et définissez l'attribut db_column sur le vrai nom du champ, tel que pass, class ou for, etc.

Par exemple, si une table contient une colonne de type INT avec le nom de colonne pour, alors le modèle généré contiendra un champ comme indiqué ci-dessous :

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

inspectdb ajoutera « renommer le champ car il s'agit d'un mot réservé Python » après le champ.

如果数据库中某张表引用了其他表（正如大多数数据库系统所做的那样），你需要适当的修改所生成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）！