| ID | English原文 | 中文翻译 | 最近翻译记录 | 状态 | 操作 |
|---|---|---|---|---|---|
| 0#翻译 | Chapter 18: | 第十八章： | 翻译 | ||
| 1#翻译 | Integrating with Legacy Databases and Applications | 集成已有的数据库和应用 | 翻译 | ||
| 4#翻译 | 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. | Django最适合于所谓的green-field开发，即从头开始的一个项目，正如你在一块还长着青草的未开垦的土地上从零开始建造一栋建筑一般。 | 翻译 | ||
| 5#翻译 | But despite the fact that Django favors from-scratch projects, it's possible to integrate the framework into legacy databases and applications. | 然而，尽管Django偏爱从头开始的项目，将这个框架和以前遗留的数据库和应用相整合仍然是可能的。 | 翻译 | ||
| 6#翻译 | This chapter explains a few integration strategies. | 本章就将介绍一些整合的技巧。 | 翻译 | ||
| 8#翻译 | Integrating with a Legacy Database | 与遗留数据库整合 | 翻译 | ||
| 10#翻译 | Django's database layer generates SQL schemas from Python code but with a legacy database, you already have the SQL schemas. | Django的数据库层从Python代码生成SQL schemas--但是对于遗留数据库，你已经拥有SQL schemas. | 翻译 | ||
| 11#翻译 | In such a case, you'll need to create models for your existing database tables. | 这种情况,你需要为已经存在的数据表创建model. | 翻译 | ||
| 12#翻译 | For this purpose, Django comes with a tool that can generate model code by reading your database table layouts. | 为此,Django自带了一个可以通过读取您的数据表结构来生成model的工具. | 翻译 | ||
| 13#翻译 | This tool is called <literal>inspectdb</literal> , and you can call it by executing the command <literal>manage.py inspectdb</literal> . | 该辅助工具称为inspectdb,你可以通过执行<literal>manage.py inspectdb</literal>来调用它. | 翻译 | ||
| 15#翻译 | Using <literal>inspectdb</literal> | 使用 <literal>inspectdb</literal> | 翻译 | ||
| 17#翻译 | The <literal>inspectdb</literal> 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. | <literal>inspectdb</literal>工具自省你配置文件指向的数据库，针对每一个表生成一个Django模型，然后将这些Python模型的代码显示在系统的标准输出里面。 | 翻译 | ||
| 19#翻译 | Here's a walk-through of a typical legacy database integration process from scratch. | 下面是一个从头开始的针对一个典型的遗留数据库的整合过程。 | 翻译 | ||
| 20#翻译 | The only assumptions are that Django is installed and that you have a legacy database. | 两个前提条件是安装了Django和一个传统数据库。 | 翻译 | ||
| 22#翻译 | Create a Django project by running <literal>django-admin.py startproject mysite</literal> (where <literal>mysite</literal> is your project's name). | 通过运行django-admin.py startproject mysite (这里 <literal>mysite</literal> 是你的项目的名字)建立一个Django项目。 | 翻译 | ||
| 23#翻译 | Well use <literal>mysite</literal> as the project name in this example. | 好的，那我们在这个例子中就用这个 <literal>mysite</literal> 作为项目的名字。 | 翻译 | ||
| 25#翻译 | Edit the settings file in that project, <literal>mysite/settings.py</literal> , to tell Django what your database connection parameters are and what the name of the database is. | 编辑项目中的配置文件, <literal>mysite/settings.py</literal> ,告诉Django你的数据库连接参数和数据库名。 | 翻译 | ||
| 26#翻译 | Specifically, provide the <literal>DATABASE_NAME</literal> , <literal>DATABASE_ENGINE</literal> , <literal>DATABASE_USER</literal> , <literal>DATABASE_PASSWORD</literal> , <literal>DATABASE_HOST</literal> , and <literal>DATABASE_PORT</literal> settings. | 具体的说，要提供 <literal>DATABASE_NAME</literal> , <literal>DATABASE_ENGINE</literal> , <literal>DATABASE_USER</literal> , <literal>DATABASE_PASSWORD</literal> , <literal>DATABASE_HOST</literal> , 和 <literal>DATABASE_PORT</literal> 这些配置信息.。 | 翻译 | ||
| 27#翻译 | (Note that some of these settings are optional. | (请注意其中的一些设置是可选的。 | 翻译 | ||
| 28#翻译 | Refer to Chapter 5 for more information.) | 更多信息参见第5章) | 翻译 | ||
| 30#翻译 | Create a Django application within your project by running <literal>python mysite/manage.py startapp myapp</literal> (where <literal>myapp</literal> is your application's name). | 通过运行 <literal>python mysite/manage.py startapp myapp</literal> (这里 <literal>myapp</literal> 是你的应用的名字)创建一个Django应用。 | 翻译 | ||
| 31#翻译 | Well use <literal>myapp</literal> as the application name here. | 这里我们使用<literal>myapp</literal> 做为应用名。 | 翻译 | ||
| 33#翻译 | Run the command <literal>python mysite/manage.py inspectdb</literal> . This will examine the tables in the <literal>DATABASE_NAME</literal> database and print the generated model class for each table. | 运行命令 <literal>python mysite/manage.py inspectdb</literal>。这将检查<literal>DATABASE_NAME</literal> 数据库中所有的表并打印出为每张表生成的模型类。 | 翻译 | ||
| 34#翻译 | Take a look at the output to get an idea of what <literal>inspectdb</literal> can do. | 看一看输出结果以了解inspectdb能做些什么。 | 翻译 | ||
| 36#翻译 | Save the output to the <literal>models.py</literal> file within your application by using standard shell output redirection: | 将标准shell的输出重定向，保存输出到你的应用的 <literal>models.py</literal> 文件里： | 翻译 | ||
| 39#翻译 | Edit the <literal>mysite/myapp/models.py</literal> file to clean up the generated models and make any necessary customizations. | 编辑 <literal>mysite/myapp/models.py</literal> 文件以清理生成的 models 并且做一些必要的自定义。 | 翻译 | ||
| 40#翻译 | We'll give some hints for this in the next section. | 针对这个，下一个节有些好的建议。 | 翻译 | ||
| 42#翻译 | Cleaning Up Generated Models | 清理生成的Models | 翻译 | ||
| 44#翻译 | As you might expect, the database introspection isn't perfect, and youll need to do some light cleanup of the resulting model code. | 如你可能会预料到的，数据库自省不是完美的，你需要对产生的模型代码做些许清理。 | 翻译 | ||
| 45#翻译 | Here are a few pointers for dealing with the generated models: | 这里提醒一点关于处理生成 models 的要点: | 翻译 | ||
| 47#翻译 | Each database table is converted to a model class (i.e., there is a one-to-one mapping between database tables and model classes). | 数据库的每一个表都会被转化为一个model类 (也就是说，数据库的表和model 类之间是一对一的映射)。 | 翻译 | ||
| 48#翻译 | This means that you'll need to refactor the models for any many-to-many join tables into <literal>ManyToManyField</literal> objects. | 这意味着你需要为多对多连接的表，重构其models 为 <literal>ManyToManyField</literal> 的对象。 | 翻译 | ||
| 50#翻译 | Each generated model has an attribute for every field, including <literal>id</literal> primary key fields. | 所生成的每一个model中的每个字段都拥有自己的属性，包括id主键字段。 | 翻译 | ||
| 51#翻译 | However, recall that Django automatically adds an <literal>id</literal> primary key field if a model doesn't have a primary key. | 但是，请注意，如果某个model没有主键的话，那么Django会自动为其增加一个id主键字段。 | 翻译 | ||
| 52#翻译 | Thus, you'll want to remove any lines that look like this: | 这样一来，你也许希望移除这样的代码行。 | 翻译 | ||
| 55#翻译 | Not only are these lines redundant, but also they can cause problems if your application will be adding <emphasis>new</emphasis> records to these tables. | 这样做并不是仅仅因为这些行是冗余的，而且如果当你的应用需要向这些表中增加新记录时，这些行会导致某些问题。 | 翻译 | ||
| 57#翻译 | Each field's type (e.g., <literal>CharField</literal> , <literal>DateField</literal> ) is determined by looking at the database column type (e.g., <literal>VARCHAR</literal> , <literal>DATE</literal> ). If <literal>inspectdb</literal> cannot map a column's type to a model field type, it will use <literal>TextField</literal> and will insert the Python comment <literal>'This field type is a guess.'</literal> next to the field in the generated model. | 每一个字段类型，如CharField、DateField， 是通过查找数据库列类型如VARCHAR,DATE来确定的。如果inspectdb无法把某个数据库字段映射到model字段上，它会使用TextField字段进行代替，并且会在所生成model字段后面加入Python注释“该字段类型是猜的”。 | 翻译 | ||
| 58#翻译 | Keep an eye out for that, and change the field type accordingly if needed. | 对这要当心，如果必要的话，更改字段类型。 | 翻译 | ||
| 60#翻译 | If a field in your database has no good Django equivalent, you can safely leave it off. | 如果你的数据库中的某个字段在Django中找不到合适的对应物，你可以放心的略过它。 | 翻译 | ||
| 61#翻译 | The Django model layer is not required to include every field in your table(s). | Django模型层不要求必须导入你数据库表中的每个列。 | 翻译 | ||
| 63#翻译 | If a database column name is a Python reserved word (such as <literal>pass</literal> , <literal>class</literal> , or <literal>for</literal> ), <literal>inspectdb</literal> will append <literal>'_field'</literal> to the attribute name and set the <literal>db_column</literal> attribute to the real field name (e.g., <literal>pass</literal> , <literal>class</literal> , or <literal>for</literal> ). | 如果数据库中某个列的名字是Python的保留字（比如pass、class或者for等），inspectdb会在每个属性名后附加上_field，并将db_column属性设置为真实的字段名（也就是pass,class或者for等）。 | 翻译 | ||
| 65#翻译 | For example, if a table has an <literal>INT</literal> column called <literal>for</literal> , the generated model will have a field like this: | 例如，某张表中包含一个INT类型的列，其列名为for，那么所生成的model将会包含如下所示的一个字段： | 翻译 | ||
| 68#翻译 | <literal>inspectdb</literal> will insert the Python comment <literal>'Field renamed because it was a Python reserved word.'</literal> next to the field. | <literal>inspectdb</literal> 会在该字段后加注 <literal>‘字段重命名，因为它是一个Python保留字’</literal> 。 | 翻译 | ||
| 70#翻译 | 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. | 如果数据库中某张表引用了其他表（正如大多数数据库系统所做的那样），你需要适当的修改所生成model的顺序，以使得这种引用能够正确映射。 | 翻译 | ||
| 71#翻译 | For example, if model <literal>Book</literal> has a <literal>ForeignKey</literal> to model <literal>Author</literal> , model <literal>Author</literal> should be defined before model <literal>Book</literal> . If you need to create a relationship on a model that has not yet been defined, you can use a string containing the name of the model, rather than the model object itself. | 例如，model Book拥有一个针对于model Author的外键，那么后者应该先于前者被定义。如果你想创建一个指向尚未定义的model的关系，那么可以使用包含model名的字符串，而不是model对象本身。 | 翻译 | ||
| 73#翻译 | <literal>inspectdb</literal> detects primary keys for PostgreSQL, MySQL, and SQLite. | 对于PostgreSQL,MySQL和SQLite数据库系统，inspectdb能够自动检测出主键关系。 | 翻译 | ||
| 74#翻译 | That is, it inserts <literal>primary_key=True</literal> where appropriate. | 也就是说，它会在合适的位置插入primary_key=True。 | 翻译 | ||
| 75#翻译 | For other databases, you'll need to insert <literal>primary_key=True</literal> for at least one field in each model, because Django models are required to have a <literal>primary_key=True</literal> field. | 而对于其他数据库系统，你必须为每一个model中至少一个字段插入这样的语句，因为Django的model要求必须拥有一个primary_key=True的字段。 | 翻译 | ||
| 77#翻译 | Foreign-key detection only works with PostgreSQL and with certain types of MySQL tables. | 外键检测仅对PostgreSQL，还有MySQL表中的某些特定类型生效。 | 翻译 | ||
| 78#翻译 | In other cases, foreign-key fields will be generated as <literal>IntegerField``s, assuming the foreign-key column was an ``INT</literal> column. | 至于其他数据库，外键字段将在假定其为INT列的情况下被自动生成为IntegerField。 | 翻译 | ||
| 80#翻译 | Integrating with an Authentication System | 与认证系统的整合 | 翻译 | ||
| 82#翻译 | It's possible to integrate Django with an existing authentication system another source of usernames and passwords or authentication methods. | 将Django与其他现有认证系统的用户名和密码或者认证方法进行整合是可以办到的。 | 翻译 | ||
| 84#翻译 | For example, your company may already have an LDAP setup that stores a username and password for every employee. | 例如，你所在的公司也许已经安装了LDAP，并且为每一个员工都存储了相应的用户名和密码。 | 翻译 | ||
| 85#翻译 | 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和基于Django的应用上拥有独立的账号，那么这时无论对于网络管理员还是用户自己来说，都是一件很令人头痛的事儿。 | 翻译 | ||
| 87#翻译 | To handle situations like this, the Django authentication system lets you plug in other authentication sources. | 为了解决这样的问题，Django认证系统能让您以插件方式与其他认证资源进行交互。 | 翻译 | ||
| 88#翻译 | You can override Django's default database-based scheme, or you can use the default system in tandem with other systems. | 您可以覆盖Diango默认的基于数据库的模式，您还可以使用默认的系统与其他系统进行交互。 | 翻译 | ||
| 90#翻译 | Specifying Authentication Backends | 指定认证后台 | 翻译 | ||
| 92#翻译 | Behind the scenes, Django maintains a list of authentication backends that it checks for authentication. | 在后台，Django维护了一个用于检查认证的后台列表。 | 翻译 | ||
| 93#翻译 | When somebody calls <literal>django.contrib.auth.authenticate()</literal> (as described in Chapter 14), Django tries authenticating across all of its authentication backends. | 当某个人调用 <literal>django.contrib.auth.authenticate()</literal> (如14章中所述)时，Django会尝试对其认证后台进行遍历认证。 | 翻译 | ||
| 94#翻译 | If the first authentication method fails, Django tries the second one, and so on, until all backends have been attempted. | 如果第一个认证方法失败，Django会尝试认证第二个，以此类推，一直到尝试完。 | 翻译 | ||
| 96#翻译 | The list of authentication backends to use is specified in the <literal>AUTHENTICATION_BACKENDS</literal> setting. | 认证后台列表在AUTHENTICATION_BACKENDS设置中进行指定。 | 翻译 | ||
| 97#翻译 | This should be a tuple of Python path names that point to Python classes that know how to authenticate. | 它应该是指向知道如何认证的Python类的Python路径的名字数组。 | 翻译 | ||
| 98#翻译 | These classes can be anywhere on your Python path. | 这些类可以在你Python路径的任何位置。 | 翻译 | ||
| 100#翻译 | By default, <literal>AUTHENTICATION_BACKENDS</literal> is set to the following: | 默认情况下，AUTHENTICATION_BACKENDS被设置为如下： | 翻译 | ||
| 103#翻译 | That's the basic authentication scheme that checks the Django users database. | 那就是检测Django用户数据库的基本认证模式。 | 翻译 | ||
| 105#翻译 | The order of <literal>AUTHENTICATION_BACKENDS</literal> matters, so if the same username and password are valid in multiple backends, Django will stop processing at the first positive match. | AUTHENTICATION_BACKENDS的顺序很重要，如果用户名和密码在多个后台中都是有效的，那么Django将会在第一个正确匹配后停止进一步的处理。 | 翻译 | ||
| 107#翻译 | Writing an Authentication Backend | 编写认证后台 | 翻译 | ||
| 109#翻译 | An authentication backend is a class that implements two methods: | 一个认证后台其实就是一个实现了如下两个方法的类： | 翻译 | ||
| 110#翻译 | <literal>get_user(id)</literal> and <literal>authenticate(**credentials)</literal> . | <literal>get_user(id)</literal> 和 <literal>authenticate(**credentials)</literal> 。 | 翻译 | ||
| 112#翻译 | The <literal>get_user</literal> method takes an <literal>id</literal> which could be a username, database ID, or whatever and returns a <literal>User</literal> object. | 方法 <literal>get_user</literal> 需要一个参数 <literal>id</literal> ，这个 <literal>id</literal> 可以是用户名，数据库ID或者其他任何数值，该方法会返回一个 <literal>User</literal> 对象。 | 翻译 | ||
| 114#翻译 | The <literal>authenticate</literal> method takes credentials as keyword arguments. | 方法 <literal>authenticate</literal> 使用证书作为关键参数。 | 翻译 | ||
| 115#翻译 | Most of the time it looks like this: | 大多数情况下，该方法看起来如下： | 翻译 | ||
| 118#翻译 | But it could also authenticate a token, like so: | 但是有时候它也可以认证某个短语，例如： | 翻译 | ||
| 121#翻译 | Either way, <literal>authenticate</literal> should check the credentials it gets, and it should return a <literal>User</literal> object that matches those credentials, if the credentials are valid. | 每一个方法中， <literal>authenticate</literal> 都应该检测它所获取的证书，并且当证书有效时，返回一个匹配于该证书的 <literal>User</literal> 对象，如果证书无效那么返回 <literal>None</literal> 。 | 翻译 | ||
| 122#翻译 | If they're not valid, it should return <literal>None</literal> . | 如果它们不合法，就返回<literal>None</literal>。 | 翻译 | ||
| 124#翻译 | The Django admin system is tightly coupled to Django's own database-backed <literal>User</literal> object described in Chapter 14. | 如14章中所述，Django管理系统紧密连接于其自己后台数据库的 <literal>User</literal> 对象。 | 翻译 | ||
| 125#翻译 | The best way to deal with this is to create a Django <literal>User</literal> object for each user that exists for your backend (e.g., in your LDAP directory, your external SQL database, etc.). | 实现这个功能的最好办法就是为您的后台数据库（如LDAP目录，外部SQL数据库等）中的每个用户都创建一个对应的Django User对象。 | 翻译 | ||
| 126#翻译 | Either you can write a script to do this in advance or your <literal>authenticate</literal> method can do it the first time a user logs in. | 您可以提前写一个脚本来完成这个工作，也可以在某个用户第一次登陆的时候在 <literal>authenticate</literal> 方法中进行实现。 | 翻译 | ||
| 128#翻译 | Here's an example backend that authenticates against a username and password variable defined in your <literal>settings.py</literal> file and creates a Django <literal>User</literal> object the first time a user authenticates: | 以下是一个示例后台程序，该后台用于认证定义在 <literal>setting.py</literal> 文件中的username和password变量，并且在该用户第一次认证的时候创建一个相应的Django <literal>User</literal> 对象。 | 翻译 | ||
| 131#翻译 | For more on authentication backends, see the official Django documentation. | 更多认证模块的后台, 参考Django文档。 | 翻译 | ||
| 133#翻译 | Integrating with Legacy Web Applications | 和遗留Web应用集成 | 翻译 | ||
| 135#翻译 | It's possible to run a Django application on the same Web server as an application powered by another technology. | 同由其他技术驱动的应用一样，在相同的Web服务器上运行Django应用也是可行的。 | 翻译 | ||
| 136#翻译 | The most straightforward way of doing this is to use Apache's configuration file, <literal>httpd.conf</literal> , to delegate different URL patterns to different technologies. | 最简单直接的办法就是利用Apaches配置文件httpd.conf，将不同的URL类型分发至不同的技术。 | 翻译 | ||
| 137#翻译 | (Note that Chapter 12 covers Django deployment on Apache/mod_python, so it might be worth reading that chapter first before attempting this integration.) | （请注意，第12章包含了在Apache/mod_python上配置Django的相关内容，因此在尝试本章集成之前花些时间去仔细阅读第12章或许是值得的。) | 翻译 | ||
| 139#翻译 | The key is that Django will be activated for a particular URL pattern only if your <literal>httpd.conf</literal> file says so. | 关键在于只有在您的httpd.conf文件中进行了相关定义，Django对某个特定的URL类型的驱动才会被激活。 | 翻译 | ||
| 140#翻译 | The default deployment explained in Chapter 12 assumes you want Django to power every page on a particular domain: | 在第12章中解释的缺省部署方案假定您需要Django去驱动某个特定域上的每一个页面。 | 翻译 | ||
| 143#翻译 | Here, the <literal><Location "/"></literal> line means handle every URL, starting at the root, with Django. | 这里, <literal><Location "/"></literal> 这一行表示用Django处理每个以根开头的URL. | 翻译 | ||
| 145#翻译 | It's perfectly fine to limit this <literal><Location></literal> directive to a certain directory tree. | 精妙之处在于Django将<location>指令值限定于一个特定的目录树上。 | 翻译 | ||
| 146#翻译 | 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 <literal>/admin/</literal> without disrupting the PHP code. | 举个例子，比如说您有一个在某个域中驱动大多数页面的遗留PHP应用，并且您希望不中断PHP代码的运行而在../admin/位置安装一个Django域。 | 翻译 | ||
| 147#翻译 | To do this, just set the <literal><Location></literal> directive to <literal>/admin/</literal> : | 要做到这一点，您只需将<location>值设置为/admin/即可。 | 翻译 | ||
| 150#翻译 | With this in place, only the URLs that start with <literal>/admin/</literal> will activate Django. | 有了这样的设置，只有那些以/admin/开头的URL地址才会触发Django去进行处理。 | 翻译 | ||
| 151#翻译 | Any other page will use whatever infrastructure already existed. | 其他页面会使用已存在的设置。 | 翻译 | ||
| 153#翻译 | Note that attaching Django to a qualified URL (such as <literal>/admin/</literal> in this section's example) does not affect the Django URL parsing. | 请注意，把Diango绑定到的合格的URL（比如在本章例子中的 <literal>/admin/</literal> ）并不会影响其对URL的解析。 | 翻译 | ||
| 154#翻译 | Django works with the absolute URL (e.g., <literal>/admin/people/person/add/</literal> ), not a stripped version of the URL (e.g., <literal>/people/person/add/</literal> ). This means that your root URLconf should include the leading <literal>/admin/</literal> . | 绝对路径对Django才是有效的（例如 <literal>/admin/people/person/add/</literal> ），而非截断后的URL（例如 <literal>/people/person/add/</literal> ）。这意味着你的根URLconf必须包含前缀 <literal>/admin/</literal> 。 | 翻译 | ||
| 156#翻译 | What's Next? | 下一章 | 翻译 | ||
| 158#翻译 | If you're a native English speaker, you might not have noticed one of the coolest features of Django's admin site: | 如果你的母语是英语, 你可能就不会注意到许多Django admin网站中最酷的特性功能。 | 翻译 | ||
| 159#翻译 | its available in more than 50 different languages! | 它支持超过50种语言! | 翻译 | ||
| 160#翻译 | This is made possible by Django's internationalization framework (and the hard work of Django's volunteer translators). | Django 的国际化框架使其成为可能( 还有Django志愿翻译者的努力 ) | 翻译 | ||
| 161#翻译 | The <reference name="next chapter" refuri="../chapter19/">next chapter</reference> explains how to use this framework to provide localized Django sites. | <reference name="next chapter" refuri="../chapter19/"> 下一章</reference> 介绍如何使用这个框架来提供本地化的Django网站。 | 翻译 |