|
ySJ
|
2.0/chapter05/#410 |
2010-04-12 13:06:06
|
自动生成的表名是app名称（ <literal>books</literal> ）和模型的小写名称 （ <literal>publisher</literal> , <literal>book</literal> , <literal>author</literal> )的组合。你可以参考附录B重写这个规则。
|
|
|
ySJ
|
2.0/chapter05/#405 |
2010-04-12 13:00:40
|
和你运行 <literal>manage.py startapp</literal> 中的一样。执行之后，输出如下：
|
|
|
ySJ
|
2.0/chapter05/#405 |
2010-04-12 13:00:16
|
和你运行 <literal>manage.py startapp</literal> 中的一样。输出如下：
|
|
|
ySJ
|
2.0/chapter05/#401 |
2010-04-12 12:59:06
|
模型确认没问题了，运行下面的命令来生成 <literal>CREATE TABLE</literal> 语句（如果你使用的是Unix，那么可以启用语法高亮）：
|
|
|
ySJ
|
2.0/chapter05/#397 |
2010-04-12 12:56:49
|
错误输出会给出非常有用的错误信息来帮助你修正你的模型。
|
|
|
ySJ
|
2.0/chapter05/#396 |
2010-04-12 11:29:16
|
如果一切正常，你会看到 <literal>0 errors found</literal> 消息。如果出错，请检查你输入的模型代码。
|
|
|
ySJ
|
2.0/chapter05/#392 |
2010-04-12 11:28:23
|
首先，用下面的命令验证模型的有效性：
|
|
|
ySJ
|
2.0/chapter05/#389 |
2010-04-12 11:27:44
|
<literal>INSTALLED_APPS</literal> 中的每个app都使用 Python的路径描述，包的路径，用小数点“.”间隔。
|
|
|
ySJ
|
2.0/chapter05/#389 |
2010-04-12 11:27:30
|
<literal>INSTALLED_APPS</literal> 中的每个app都使用 Python的路径描述，包的路径，用小数点“.”区分。
|
|
|
ySJ
|
2.0/chapter05/#388 |
2010-04-12 11:26:31
|
<literal>'mysite.books'</literal>指示我们正在编写的<literal>books</literal> app。
|
|
|
ySJ
|
2.0/chapter05/#386 |
2010-04-12 11:25:22
|
这是为了避免忘了加逗号，而且也没什么坏处。)
|
|
|
ySJ
|
2.0/chapter05/#372 |
2010-04-12 11:20:57
|
将 <literal>books</literal> app 添加到配置文件的已安装应用列表中即可完成此步骤。
|
|
|
ySJ
|
2.0/chapter05/#366 |
2010-04-12 11:19:40
|
除非你单独指明，否则Django会自动为每个模型生成一个自增长的整数主键字段<literal></literal>每个Django模型都要求有单独的主键。
|
|
|
ySJ
|
2.0/chapter05/#365 |
2010-04-12 11:16:27
|
最后需要注意的是，我们并没有显式地为这些模型定义任何主键。
|
|
|
ySJ
|
2.0/chapter05/#354 |
2010-04-12 11:13:27
|
属性名就是字段名，它的类型（例如 <literal>CharField</literal> ）相当于数据库的字段类型 （例如 <literal>varchar</literal> ）。例如， <literal>Publisher</literal> 模块等同于下面这张表（用PostgreSQL的 <literal>CREATE TABLE</literal> 语法描述）：
|
|
|
ySJ
|
2.0/chapter05/#351 |
2010-04-12 11:11:39
|
信不信由你，这些就是我们需要编写的通过Django存取基本数据的所有代码。
|
|
|
ySJ
|
2.0/chapter05/#351 |
2010-04-12 11:11:20
|
信不信由你，这些就是我们通过Django存取基本数据的所有代码。
|
|
|
ySJ
|
2.0/chapter05/#350 |
2010-04-12 11:08:48
|
首先要注意的事是每个数据模型都是 <literal>django.db.models.Model</literal> 的子类。它的父类 Model 包含了所有必要的和数据库交互的方法，并提供了一个简洁漂亮的定义数据库字段的语法。
|
|
|
ySJ
|
2.0/chapter05/#332 |
2010-04-12 11:04:53
|
在本章和后续章节里，我们把注意力放在一个基本的 书籍/作者/出版商 数据库结构上。
|
|
|
ySJ
|
2.0/chapter05/#323 |
2010-04-12 11:03:02
|
如果你修改了一个Django模型， 你要自己来修改数据库来保证和模型同步。
|
|
|
ySJ
|
2.0/chapter05/#320 |
2010-04-12 10:58:57
|
发布Web应用的时候，使用Python模块描述数据库结构信息可以避免为MySQL, PostgreSQL, and SQLite编写不同的<literal>CREATE TABLE</literal>。
|
|
|
ySJ
|
2.0/chapter05/#317 |
2010-04-12 10:55:22
|
好处就是高级的数据类型带来更高的效率和更好的代码复用。
|
|
|
ySJ
|
2.0/chapter05/#315 |
2010-04-12 10:54:39
|
例如，大多数数据库都没有专用的字段类型来描述Email地址、URL。
|
|
|
ySJ
|
2.0/chapter05/#308 |
2010-04-12 10:52:30
|
尽可能的保持在单一的编程环境/思想状态下可以帮助你提高生产率。
|
|
|
ySJ
|
2.0/chapter05/#300 |
2010-04-12 10:47:51
|
第一种方式是用Python明确地定义数据模型，第二种方式是通过自省来自动侦测识别数据模型。
|
|
|
ySJ
|
2.0/chapter05/#293 |
2010-04-12 10:45:51
|
Django也使用模型来呈现SQL无法处理的高级概念。
|
|
|
ySJ
|
2.0/chapter05/#293 |
2010-04-12 10:45:35
|
Django也使用模型来城乡SQL无法处理的高级概念。
|
|
|
ySJ
|
2.0/chapter05/#292 |
2010-04-12 10:44:15
|
Django用模型在后台执行SQL代码并把结果用Python的数据结构来描述。
|
|
|
ySJ
|
2.0/chapter05/#291 |
2010-04-12 10:43:25
|
对数据层来说它等同于 CREATE TABLE 语句，只不过执行的是Python代码而不是 SQL，而且还包含了比数据库字段定义更多的含义。
|
|
|
ySJ
|
2.0/chapter05/#290 |
2010-04-12 10:42:19
|
Django模型是用Python代码形式表述的数据在数据库中的定义。
|
|
|
ySJ
|
2.0/chapter05/#289 |
2010-04-12 10:41:48
|
我们早些时候谈到。MTV里的M代表模型。
|
|
|
ySJ
|
2.0/chapter05/#289 |
2010-04-12 10:41:35
|
我们早些时候谈到。MTV里的M代表模型
|
|
|
ySJ
|
2.0/chapter05/#285 |
2010-04-12 10:41:04
|
它们都是空的，除了 <literal>models.py</literal> 里有一个 import。这就是你Django app的基础。
|
|
|
ySJ
|
2.0/chapter05/#284 |
2010-04-12 10:37:43
|
使用你最喜欢的文本编辑器查看一下 <literal>models.py</literal> 和 <literal>views.py</literal> 文件的内容。
|
|
|
ySJ
|
2.0/chapter05/#275 |
2010-04-12 10:36:36
|
在<literal> mysite</literal> 项目文件下输入下面的命令来创建<literal> books</literal> app：
|
|
|
ySJ
|
2.0/chapter05/#271 |
2010-04-12 10:36:03
|
如果你使用了Django的数据库层（模型），你 必须创建一个Django app。
|
|
|
ySJ
|
2.0/chapter05/#267 |
2010-04-12 10:35:24
|
在那些例子中，我们只是简单的创建了一个称为<literal>views.py</literal>的文件，编写了一些函数并在URLconf中设置了各个函数的映射。
|
|
|
ySJ
|
2.0/chapter05/#266 |
2010-04-12 10:34:13
|
不错，你可以不用创建app，这一点应经被我们之前编写的视图函数的例子证明了 。
|
|
|
ySJ
|
2.0/chapter05/#264 |
2010-04-12 10:31:58
|
但如果是一个包含许多不相关的模块的复杂的网站，例如电子商务和社区之类的站点，那么你可能需要把这些模块划分成不同的app，以便以后复用。
|
|
|
ySJ
|
2.0/chapter05/#263 |
2010-04-12 10:31:11
|
如果你只是建造一个简单的Web站点，那么可能你只需要一个app就可以了；
|
|
|
ySJ
|
2.0/chapter05/#260 |
2010-04-12 10:29:05
|
app的一个关键点是它们是很容易移植到其他project和被多个project复用。
|
|
|
ySJ
|
2.0/chapter05/#251 |
2010-04-12 10:25:24
|
代码：
|
|
|
ySJ
|
2.0/chapter05/#250 |
2010-04-12 10:25:14
|
在第二章我们已经创建了 <emphasis>project</emphasis> , 那么 <emphasis>project</emphasis> 和 <emphasis>app</emphasis> 之间到底有什么不同呢？它们的区别就是一个是配置另一个是
|
|
|
ySJ
|
2.0/chapter05/#247 |
2010-04-12 10:22:45
|
你现在已经确认数据库连接正常工作了，让我们来创建一个 <emphasis>Django app</emphasis>-一个包含模型，视图和Django代码，并且形式为独立Python包的完整Django应用。
|
|
|
ySJ
|
2.0/chapter05/#230 |
2010-04-12 10:14:58
|
把<literal>DATABASE_ENGINE</literal> 配置成前面提到的合法的数据库引擎。
|
|
|
ySJ
|
2.0/chapter05/#226 |
2010-04-12 10:13:30
|
未安装合适的数据库适配器 (例如, <literal>psycopg</literal> 或 <literal>MySQLdb</literal> )。Django并不自带适配器，所以你得自己下载安装。
|
|
|
ySJ
|
2.0/chapter05/#221 |
2010-04-12 10:10:58
|
使用<literal> python manager.py shell</literal> 命令启动交互解释器，不要以<literal> python</literal> 命令直接启动交互解释器。
|
|
|
ySJ
|
2.0/chapter05/#216 |
2010-04-12 10:10:01
|
不要以空字符串配置<literal> DATABASE_ENGINE</literal> 的值。
|
|
|
ySJ
|
2.0/chapter05/#197 |
2010-04-12 10:07:08
|
这个方法在这里是很有必要的，因为Django需要知道加载哪个配置文件来获取数据库连接信息。）
|
|
|
ySJ
|
2.0/chapter05/#196 |
2010-04-12 10:04:56
|
（我们上一章提到过在，<literal> manager.py shell</literal> 命令是以正确Django配置启用Python交互解释器的一种方法。
|
|
