Django Book 翻译

Chapter 16: Integrating with Legacy Databases and Applications
--------------------------------------------------------------

第十六章 集成已有的数据库和应用
--------------------------------------------------------------

Django is best suited for so-called green-field development that is, starting
projects from scratch, as if you were constructing a building on a fresh field
of green grass. But despite the fact that Django favors from-scratch projects,
its possible to integrate the framework into legacy databases and applications.
This chapter explains a few integration strategies.

Django最适合于所谓的green-field开发，即从头开始的一个项目，正如你在一块还长着青草的未开垦的土地上从零开始建造一栋建筑一般。然而，尽管Django偏爱从头开始的项目，将这个框架和以前遗留的数据库和应用相整合仍然是可能的。本章就将介绍一些整合的技巧。

Integrating with a Legacy Database
``````````````````````````````````

与遗留数据库整合
``````````````````````````````````

Djangos database layer generates SQL schemas from Python code but with a legacy
database, you already have the SQL schemas. In such a case, youll need to
create models for your existing database tables. For this purpose, Django comes
with a tool that can generate model code by reading your database table
layouts. This tool is called ``inspectdb`` , and you can call it by executing
the command ``manage.py inspectdb`` .

Django的数据库层从Python代码生成SQL schemas--但是对于遗留数据库，你已经拥有SQL schemas，这种情况下你需要为你
已经存在的数据库表写模型(由于性能的原因，Django的数据库层不支持通过运行时自省数据库的不工作的对象-关系映射，
为了使用数据库API，你需要写模型代码)，幸运的是，Django带有通过阅读你的数据库表规划来生成模型代码的辅助工具
该辅助工具称为manage.py inspectdb 

Using ``inspectdb``
'''''''''''''''''''

使用 ``inspectdb``
'''''''''''''''''''

The ``inspectdb`` utility introspects the database pointed to by your settings
file, determines a Django model representation for each of your tables, and
prints the Python model code to standard output.

The ``inspectdb`` 工具内省检查你的配置文件（setting file）指向的数据库，针对你的每一个表生成一个Django model的表现，然后将这些Python model的代码显示在系统的标准输出里面。

Heres a walk-through of a typical legacy database integration process from
scratch. The only assumptions are that Django is installed and that you have a
legacy database.

下面是一个从头开始的针对一个典型的遗留数据库的整合过程

    Create a Django project by running ``django-admin.py startproject mysite``
    (where ``mysite`` is your projects name). Well use ``mysite`` as the
    project name in this example.

通过运行django-admin.py startproject mysite (这里 ``mysite`` 是你的项目的名字)建立一个Django项目。好的，那我们在这个例子中就用这个 ``mysite`` 作为项目的名字。

    Edit the settings file in that project, ``mysite/settings.py`` , to tell
    Django what your database connection parameters are and what the name of
    the database is. Specifically, provide the ``DATABASE_NAME`` ,
    ``DATABASE_ENGINE`` , ``DATABASE_USER`` , ``DATABASE_PASSWORD`` ,
    ``DATABASE_HOST`` , and ``DATABASE_PORT`` settings. (Note that some of
    these settings are optional. Refer to Chapter 5 for more information.)

    编辑项目中的配置文件, ``mysite/settings.py`` ,告诉Django你的数据库连接参数和数据库名。具体的说，要提供 ``DATABASE_NAME`` ,
    ``DATABASE_ENGINE`` , ``DATABASE_USER`` , ``DATABASE_PASSWORD`` ,
    ``DATABASE_HOST`` , 和 ``DATABASE_PORT`` 这些配置信息. (注意,这里面有些配置项是可选的，更多信息参考第五章）

    Create a Django application within your project by running ``python
    mysite/manage.py startapp myapp`` (where ``myapp`` is your applications
    name). Well use ``myapp`` as the application name here.

    通过运行 ``python mysite/manage.py startapp myapp`` (这里 ``myapp`` 是你的应用的名字)创建一个Django应用.那么,我们就以 ``myapp`` 做为这个应用的名字.

    Run the command ``python mysite/manage.py inspectdb`` . This will examine
    the tables in the ``DATABASE_NAME`` database and print the generated model
    class for each table. Take a look at the output to get an idea of what
    ``inspectdb`` can do.

Mgi4P7  <a href="http://egawnqpydxgr.com/">egawnqpydxgr</a>, [url=http://pqxrfbeebwlx.com/]pqxrfbeebwlx[/url], [link=http://ayerpdvfcibx.com/]ayerpdvfcibx[/link], http://oiclqzyfemdn.com/

    Save the output to the ``models.py`` file within your application by using
    standard shell output redirection:

    将标准shell的输出重定向，保存输出到你的应用的 ``models.py`` 文件里：

    Edit the ``mysite/myapp/models.py`` file to clean up the generated models
    and make any necessary customizations. Well give some hints for this in the
    next section.

    编辑 ``mysite/myapp/models.py`` 文件以清理生成的 models 以及一些必要的定制化。
    下一个章节对此有些好的建议。

Cleaning Up Generated Models
''''''''''''''''''''''''''''

BJuyYO  <a href="http://gudqbthrquuw.com/">gudqbthrquuw</a>, [url=http://nnferpaaqtza.com/]nnferpaaqtza[/url], [link=http://pkxlmlxjxtow.com/]pkxlmlxjxtow[/link], http://hvuszhvyijlw.com/

As you might expect, the database introspection isnt perfect, and youll need to
do some light cleanup of the resulting model code. Here are a few pointers for
dealing with the generated models:

如你可能会预料到的，数据库自省不是完美的，你需要对产生的模型代码做些许清理。
这里提醒一点关于处理生成 models 的要点:

    Each database table is converted to a model class (i.e., there is a
    one-to-one mapping between database tables and model classes). This means
    that youll need to refactor the models for any many-to-many join tables
    into ``ManyToManyField`` objects.

dMtfgT  <a href="http://ofpjyxnfjlnj.com/">ofpjyxnfjlnj</a>, [url=http://dpixdvamofrx.com/]dpixdvamofrx[/url], [link=http://ivaqvrambdds.com/]ivaqvrambdds[/link], http://owvunzpidrey.com/

    Each generated model has an attribute for every field, including ``id``
    primary key fields. However, recall that Django automatically adds an
    ``id`` primary key field if a model doesnt have a primary key. Thus, youll
    want to remove any lines that look like this:

所生成的每一个model中的每个字段都拥有自己的属性，包括id主键字段。但是，请注意，如果某个model没有主键的话，那么Django会自动为其增加一个Id主键字段。这样一来，你也许希望使用如下代码来对任意行执行删除操作：

    Not only are these lines redundant, but also they can cause problems if
    your application will be adding *new* records to these tables. The
    ``inspectdb`` command cannot detect whether a field is autoincremented, so
    its up to you to change this to ``AutoField`` , if necessary.

这样做并不是仅仅因为这些行是冗余的，而且如果当你的应用需要向这些表中增加新记录时，这些行会导致某些问题。而inspectdb命令并不能检测出一个字段是否自增长的，因此必要的时候，你必须将他们修改为AutoField.

    Each fields type (e.g., ``CharField`` , ``DateField`` ) is determined by
    looking at the database column type (e.g., ``VARCHAR`` , ``DATE`` ). If
    ``inspectdb`` cannot map a columns type to a model field type, it will use
    ``TextField`` and will insert the Python comment ``'This field type is a
    guess.'`` next to the field in the generated model. Keep an eye out for
    that, and change the field type accordingly if needed.

每一个字段类型，如CharField、DateField， 是通过查找数据库列类型如VARCHAR,DATE来确定的。如果inspectdb无法对某个model字段类型根据数据库列类型进行映射，那么它会使用TextField字段进行代替，并且会在所生成model字段后面加入Python注释“该字段类型是猜的”。因此，请特别注意这一点，并且在必要的时候相应的修改这些字段类型。

    If a field in your database has no good Django equivalent, you can safely
    leave it off. The Django model layer is not required to include every field
    in your table(s).

如果你的数据库中的某个字段在Django中找不到合适的对应物，你可以放心的略过它，因为Django层并没有要求必须包含你的表中的每一个字段。

    If a database column name is a Python reserved word (such as ``pass`` ,
    ``class`` , or ``for`` ), ``inspectdb`` will append ``'_field'`` to the
    attribute name and set the ``db_column`` attribute to the real field name
    (e.g., ``pass`` , ``class`` , or ``for`` ).

如果数据库中某个列的名字是Python的保留字，比如pass、class或者for等，inspectdb会在每个属性名后附加上_field，并将db_column属性设置为真实的字段名，比如pass,class或者for等。

    For example, if a table has an ``INT`` column called ``for`` , the
    generated model will have a field like this:

例如，某张表中包含一个INT类型的列，其列名为for，那么所生成的model将会包含如下所示的一个字段：

    ``inspectdb`` will insert the Python comment ``'Field renamed because it
    was a Python reserved word.'`` next to the field.

jBI57S  <a href="http://jillralfgjok.com/">jillralfgjok</a>, [url=http://eofkzwzlxabw.com/]eofkzwzlxabw[/url], [link=http://zbzzidjvvvxl.com/]zbzzidjvvvxl[/link], http://dsxsfstfqzfy.com/

    If your database contains tables that refer to other tables (as most
    databases do), you might need to rearrange the order of the generated
    models so that models that refer to other models are ordered properly. For
    example, if model ``Book`` has a ``ForeignKey`` to model ``Author`` , model
    ``Author`` should be defined before model ``Book`` . If you need to create
    a relationship on a model that has not yet been defined, you can use the
    name of the model, rather than the model object itself.

如果数据库中某张表引用了其他表（正如大多数数据库系统所做的那样），你需要适当的修改所生成model的顺序，以使得这种引用能够正确映射。例如，model Book拥有一个针对于model Author的外键，那么后者应该先于前者被定义。如果你需要为一个还没有被定义的model创建一个关系，那么你可以使用该model的名字，而不是model对象本身。

    ``inspectdb`` detects primary keys for PostgreSQL, MySQL, and SQLite. That
    is, it inserts ``primary_key=True`` where appropriate. For other databases,
    youll need to insert ``primary_key=True`` for at least one field in each
    model, because Django models are required to have a ``primary_key=True``
    field.

对于PostgreSQL,MySQL和SQLite数据库系统，inspectdb能够自动检测出主键关系。也就是说，它会在合适的位置插入primary_key=True。而对于其他数据库系统，你必须为每一个model中至少一个字段插入这样的语句，因为Django的model要求必须拥有一个primary_key=True的字段。

    Foreign-key detection only works with PostgreSQL and with certain types of
    MySQL tables. In other cases, foreign-key fields will be generated as
    ``IntegerField``s, assuming the foreign-key column was an ``INT`` column.

外键检测仅对PostgreSQL，还有MySQL表中的某些特定类型生效。至于其他数据库，外键字段都将在假定其为INT列的情况下被自动生成为IntegerField。

Integrating with an Authentication System
`````````````````````````````````````````

与认证系统的整合

Its possible to integrate Django with an existing authentication system another
source of usernames and passwords or authentication methods.

将Django与其他现有认证系统的用户名和密码或者认证方法进行整合是可以办到的。

For example, your company may already have an LDAP setup that stores a username
and password for every employee. It would be a hassle for both the network
administrator and the users themselves if users had separate accounts in LDAP
and the Django-based applications.

例如，你所在的公司也许已经安装了LDAP，并且为每一个员工都存储了相应的用户名和密码。如果用户在LDAP和基于Django的应用上拥有独立的账号，那么这时无论对于网络管理员还是用户自己来说，都是一件很令人头痛的事儿。

To handle situations like this, the Django authentication system lets you plug
in other authentication sources. You can override Djangos default
database-based scheme, or you can use the default system in tandem with other
systems.

为了解决这样的问题，Django认证系统能让您以插件方式与其他认证资源进行交互。您可以覆盖Diangos的默认基于数据库模式，您还可以使用默认的系统与其他系统进行交互。

Specifying Authentication Back-ends
'''''''''''''''''''''''''''''''''''

指定认证后台

Behind the scenes, Django maintains a list of authentication back-ends that it
checks for authentication. When somebody calls
``django.contrib.auth.authenticate()`` (as described in Chapter 12), Django
tries authenticating across all of its authentication back-ends. If the first
authentication method fails, Django tries the second one, and so on, until all
back-ends have been attempted.

在后台，Django维护了一个用于检查认证的后台列表。当某个人调用 ``django.contrib.auth.authenticate()`` (如12章中所述)时，Django会尝试对其认证后台进行遍历认证。如果第一个认证方法失败，Django会尝试认证第二个，以此类推，一直到尝试完。

The list of authentication back-ends to use is specified in the
``AUTHENTICATION_BACKENDS`` setting. This should be a tuple of Python path
names that point to Python classes that know how to authenticate. These classes
can be anywhere on your Python path.

认证后台列表在AUTHENTICATION_BACKENDS设置中进行指定，它应该是指向知道如何认证的Python类的Python路径的名字数组，这些类可以放置在您的Python路径的任何位置上。

By default, ``AUTHENTICATION_BACKENDS`` is set to the following:

默认情况下，AUTHENTICATION_BACKENDS被设置为如下：

Thats the basic authentication scheme that checks the Django users database.

那就是检测Django用户数据库的基本认证模式。

The order of ``AUTHENTICATION_BACKENDS`` matters, so if the same username and
password are valid in multiple back-ends, Django will stop processing at the
first positive match.

对于多个顺序组合的AUTHENTICATION_BACKENDS，如果其用户名和密码在多个后台中都是有效的，那么Django将会在第一个正确通过认证后停止进一步的处理。

Writing an Authentication Back-end
''''''''''''''''''''''''''''''''''

如何写一个认证后台

An authentication back-end is a class that implements two methods:
``get_user(id)`` and ``authenticate(**credentials)`` .

一个认证后台其实就是一个实现了如下两个方法的类： ``get_user(id)`` 和 ``authenticate(**credentials)`` 。

The ``get_user`` method takes an ``id`` which could be a username, database ID,
or whatever and returns a ``User`` object.

方法 ``get_user`` 需要一个参数 ``id`` ，这个 ``id`` 可以是用户名，数据库ID或者其他任何数值，该方法会返回一个 ``User`` 对象。

The ``authenticate`` method takes credentials as keyword arguments. Most of the
time it looks like this:

方法 ``authenticate`` 使用证书作为关键参数。大多数情况下，该方法看起来如下：

But it could also authenticate a token, like so:

但是有时候它也可以认证某个令牌，例如：

Either way, ``authenticate`` should check the credentials it gets, and it
should return a ``User`` object that matches those credentials, if the
credentials are valid. If theyre not valid, it should return ``None`` .

每一个方法中， ``authenticate`` 都应该检测它所获取的证书，并且当证书有效时，返回一个匹配于该证书的 ``User`` 对象，如果证书无效那么返回 ``None`` 。

The Django admin system is tightly coupled to Djangos own database-backed
``User`` object described in Chapter 12. The best way to deal with this is to
create a Django ``User`` object for each user that exists for your back-end
(e.g., in your LDAP directory, your external SQL database, etc.). Either you
can write a script to do this in advance or your ``authenticate`` method can do
it the first time a user logs in.

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

Heres an example back-end that authenticates against a username and password
variable defined in your ``settings.py`` file and creates a Django ``User``
object the first time a user authenticates:

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

Integrating with Legacy Web Applications
````````````````````````````````````````

和遗留Web应用集成
````````````````````````````````````````

Its possible to run a Django application on the same Web server as an
application powered by another technology. The most straightforward way of
doing this is to use Apaches configuration file, ``httpd.conf`` , to delegate
different URL patterns to different technologies. (Note that Chapter 20 covers
Django deployment on Apache/mod_python, so it might be worth reading that
chapter first before attempting this integration.)

同由其他技术驱动的应用一样，在相同的Web服务器上运行Django应用也是可行的。最简单直接的办法就是利用Apaches配置文件httpd.conf，将不同的URL类型代理至不同的技术。（请注意，第20章包含了在Apache/mod_python上配置Django的相关内容，因此在尝试本章集成之前花些时间去仔细阅读第20章或许是值得的。）

The key is that Django will be activated for a particular URL pattern only if
your ``httpd.conf`` file says so. The default deployment explained in Chapter
20 assumes you want Django to power every page on a particular domain:

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

Here, the ``<Location "/">`` line means handle every URL, starting at the root,
with Django.

这里,  ``<Location "/">`` 这一行表示用Django处理每个以根开头的URL.

Its perfectly fine to limit this ``<Location>`` directive to a certain
directory tree. For example, say you have a legacy PHP application that powers
most pages on a domain and you want to install a Django admin site at
``/admin/`` without disrupting the PHP code. To do this, just set the
``<Location>`` directive to ``/admin/`` :

精妙之处在于Django将<location>指令值限定于一个特定的目录树上。举个例子，比如说您有一个在某个域中驱动大多数页面的遗留PHP应用，并且您希望不中断PHP代码的运行而在../admin/位置安装一个Django域。要做到这一点，您只需将<location>值设置为/admin/即可。

With this in place, only the URLs that start with ``/admin/`` will activate
Django. Any other page will use whatever infrastructure already existed.

KshJiK  <a href="http://hychpznxvvpz.com/">hychpznxvvpz</a>, [url=http://idhrtvjehost.com/]idhrtvjehost[/url], [link=http://yssfucouapzc.com/]yssfucouapzc[/link], http://hsoazioekrvi.com/

Note that attaching Django to a qualified URL (such as ``/admin/`` in this
sections example) does not affect the Django URL parsing. Django works with the
absolute URL (e.g., ``/admin/people/person/add/`` ), not a stripped version of
the URL (e.g., ``/people/person/add/`` ). This means that your root URLconf
should include the leading ``/admin/`` .

请注意，把Diango绑定到的合格的URL（比如在本章例子中的 ``/admin/`` ）并不会影响其对URL的解析。绝对路径对Django才是有效的（例如 ``/admin/people/person/add/`` ），而非截断后的URL（例如 ``/people/person/add/`` ）。这意味着你的根URLconf必须包含前缀 ``/admin/`` 。

Whats Next?
```````````

aoRVhS  <a href="http://rxhmltxgkdkj.com/">rxhmltxgkdkj</a>, [url=http://wmhujqrawkcu.com/]wmhujqrawkcu[/url], [link=http://blebolfmttir.com/]blebolfmttir[/link], http://tvqjecsbdnap.com/

Speaking of the Django admin site and bending the framework to fit legacy
needs, another common task is to customize the Django admin site. The next
chapter focuses on such customization.

谈到Django管理站点和让整个框架服从于遗留Web集成需求时，另一个常见任务就是定制Django管理站点。我们会在下一章中聚焦类似的定制。