Django笔记：5.激活模型

激活模型

上篇中的模型代码给了Django很多信息。 有了这些代码，Django就能够：

• 为该应用创建数据库表（CREATE TABLE 语句）。
• 为Question对象和Choice对象创建一个访问数据库的python API。

但是，我们首先得告诉项目：polls应用已经安装。 

理念

Django 应用是可以“热插拔”的，即可以在多个项目中使用同一个应用，也可以分发这些应用， 因为它们不需要与某个特定的Django安装绑定。

再次编辑mysite/settings.py文件，并修改INSTALLED_APPS设置以包含字符串'polls'。现在它是这样的：

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'polls',
]

现在Django知道要包含polls应用。 让我们在cmd运行另外一个命令：

python manage.py makemigrations polls

你应该看到类似下面的内容：

Migrations for 'polls':
  0001_initial.py:
    - Create model Question
    - Create model Choice
    - Add field question to choice

通过运行makemigrations告诉Django，已经对模型做了一些更改（在这个例子中，你创建了一个新的模型）并且会将这些更改存储为迁移文件。

Django使用迁移文件来保存对模型的更改（即数据库模式的更改）—— 所谓迁移文件其实就是磁盘上的普通文件。 如果愿意，你可以阅读迁移文件来了解新模型； 这个迁移文件就是  polls/migrations/0001_initial.py。不用担心，Django不要求你在每次Django生成迁移文件之后都要阅读这些文件，但是它们被设计成可人为编辑的形式，以便你可以手工稍微修改一下Django的某些具体行为。

有一个命令可以运行这些迁移文件并自动管理你的数据库模式 —— 它叫做migrate，我们一会儿会用到它 —— 但是首先，让我们看一下迁移行为将会执行哪些SQL语句。sqlmigrate命令接收迁移文件的名字并返回它们的SQL语句：

python manage.py sqlmigrate polls 0001

你应该会看到类似如下的内容（为了便于阅读我们对它重新编排了格式）：BEGIN;--

BEGIN;

CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);

CREATE TABLE "polls_question" (
    "id" serial NOT NULL PRIMARY KEY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);

ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
ALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;
CREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;

COMMIT;

请注意以下几点：

• 输出的具体内容会依据你使用的数据库而不同。 以上例子使用的数据库是PostgreSQL。
• 表名是自动生成的，由app的名字（polls）和模型名字的小写字母组合而成 —— question和choice。（你可以重写这个行为。)
• 主键（IDs）是自动添加的。 （你也可以重写这个行为。)
• 按照惯例，Django会在外键的字段名后面添加 "_id"。（是的，你依然可以重写这个行为。）
• 外键关系由FOREIGN KEY约束显式声明。不用在意DEFERRABLE部分；它只是告诉PostgreSQL直到事务的最后再执行外键关联。
• 这些SQL语句是针对你所使用的数据库定制的，所以会为你自动处理某些数据库所特有的字段例如auto_increment (MySQL)、 serial(PostgreSQL)或integer primary key autoincrement (SQLite) 。在处理字段名的引号时也是如此 —— 例如，使用双引号还是单引号。
• sqlmigrate命令并不会在你的数据库上真正运行迁移文件 —— 它只是把Django 认为需要的SQL打印在屏幕上以让你能够看到。 这对于检查Django将要进行的数据库操作或者你的数据库管理员需要这些SQL脚本是非常有用的。

如果有兴趣，你还可以运行python manage.py check；它会检查你的项目中的模型是否存在问题，而不用执行迁移或者接触数据库。

python manage.py migrate

返回以下结果：

Operations to perform:
  Apply all migrations: polls, contenttypes, auth, sessions, admin
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK

migrate命令会找出所有还没有被应用的迁移文件（Django使用数据库中一个叫做django_migrations的特殊表来追踪哪些迁移文件已经被应用过），并且在你的数据库上运行它们 —— 本质上来讲，就是使你的数据库模式和你改动后的模型进行同步。

迁移功能非常强大，可以让你在开发过程中不断修改你的模型而不用删除数据库或者表然后再重新生成一个新的 —— 它专注于升级你的数据库且不丢失数据。 我们将在本教程的后续章节对迁移进行深入地讲解，但是现在，请记住实现模型变更的三个步骤：

• 修改你的模型（在models.py文件中）。
• 运行python manage.py makemigrations ，为这些修改创建迁移文件
• 运行python manage.py migrate ，将这些改变更新到数据库中。

将生成和应用迁移文件的命令分成几个命令来执行，是因为你可能需要将迁移文件提交到你的版本控制系统中并跟随你的应用一起变化； 这样做不仅可以使开发变得更加简单，而且对其他开发者以及上线生产非常有用。

阅读django-admin 的文档来了解manage.py 工具能做的所有事情。