当你首次创建一个应用的时候,为你的数据库预先安装一些硬编码的数据,是颇有用处的。 有几种方法可让Django自动建立这些数据:你能够经过fixtures提供初始数据,或者提供一个包含初始数据的sql文件。html
一般来说,使用fixtrue更加简洁,由于它是数据库无关的,而使用sql初始化更加灵活。python
fixture是数据的集合,让Django了解如何导入到数据库中。建立fixture的最直接的方式,是使用manage.py dumpdata命令,若是数据库中已经有了一些数据。或者你能够手写fixtures。fixtures支持JSON、XML或者YAML(须要安装PyYAML)文档。序列化文档中详细阐述了每一种所支持的序列化格式。git
下面这个例子展现了一个简单的Person 模型的fixtrue,看起来很像JSON:github
[ { "model": "myapp.person", "pk": 1, "fields": { "first_name": "John", "last_name": "Lennon" } }, { "model": "myapp.person", "pk": 2, "fields": { "first_name": "Paul", "last_name": "McCartney" } } ]
下面是它的YAML格式:sql
- model: myapp.person pk: 1 fields: first_name: John last_name: Lennon - model: myapp.person pk: 2 fields: first_name: Paul last_name: McCartney
你能够把这些数据储存在你应用的fixtures目录中。数据库
加载数据很简单:只要调用manage.py loaddata <fixturename>就行了,其中<fixturename>是你所建立的fixture文件的名字。每次你运行loaddata的时候,数据都会从fixture读出,而且重复加载进数据库。注意这意味着,若是你修改了fixtrue建立的某一行,而后再次运行了 loaddata,你的修改将会被抹掉。django
1.7中废除: 若是一个应用使用了迁移,将不会自动加载fixtures。因为Django 1.9中,迁移将会是必要的,这一行为经权衡以后被废除。 若是你想在一个应用中加载初始数据,考虑在数据迁移中加载它们。
若是你建立了一个命名为 initial_data.[xml/yaml/json]的fixtrue,在你每次运行migrate命令时,fixtrue都会被加载。这很是方面,可是要注意:记住数据在你每次运行migrate命令后都会被刷新。So don’t use initial_data for data you’ll want to edit.json
一般,Django 在每一个应用的fixtures目录中寻找fixture文件。你能够设置FIXTURE_DIRS选项为一个额外目录的列表,Django会从里面寻找。后端
运行manage.py loaddata命令的时候,你也能够指定一个fixture文件的目录,它会覆盖默认设置中的目录。app
另见
fixtrues也被用于测试框架来搭建一致性的测试环境。
1.7中废除: 若是一个应用使用迁移,初始SQL数据将不会加载(包括后端特定的SQL数据)。因为Django 1.9中,迁移将会是必须的,这一行为经权衡后被废除。若是你想在应用中使用初始SQL数据,考虑在数据迁移中使用它们。
Django为数据库无关的SQL提供了一个钩子,当你运行migrate命令时,CREATE TABLE语句执行以后就会执行它。你可使用这个钩子来创建默认的记录,或者建立SQL函数、视图、触发器以及其它。
钩子十分简单:Django会在你应用的目录中寻找叫作sql/<modelname>.sql的文件,其中 <modelname>是小写的模型名称。
因此若是在myapp应用中存在Person模型,你应该在myapp目录的文件sql/person.sql中添加数据库无关的SQL。下面的例子展现了文件可能会包含什么:
INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon'); INSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney');
每一个提供的SQL文件,都应该含有用于插入数据的有效的SQL语句(例如,格式适当的INSERT语句,用分号分隔)。
这些SQL文件可被manage.py中的 sqlcustom和sqlall命令阅读。详见manage.py文档。
注意若是你有不少SQL数据文件,他们执行的顺序是不肯定的。惟一能够肯定的是,在你的自定义数据文件被执行以前,全部数据表都被建立好了。
初始SQL数据和测试
这一技巧不能以测试目的用于提供初始数据。Django的测试框架在每次测试后都会刷新测试数据库的内容。因此,任何使用自定义SQL钩子添加的数据都会丢失。
若是你须要在测试用例中添加数据,你应该在测试fixture中添加它,或者在测试用例的setUp()中添加。
没有钩子提供给后端特定的SQL数据。例如,你有分别为PostgreSQL和SQLite准备的初始数据文件。对于每一个应用,Django都会寻找叫作<app_label>/sql/<modelname>.<backend>.sql的文件,其中<app_label>是小写的模型名称,<modelname>是小写的模型名称,<backend>是你的设置文件中由ENGINE提供的模块名称的最后一部分(例如,若是你定义了一个数据库,ENGINE的值为django.db.backends.sqlite3,Django会寻找<app_label>/sql/<modelname>.sqlite3.sql)。
后端特定的SQL数据会先于后端无关的SQL数据执行。例如,若是你的应用包含了sql/person.sql 和sql/person.sqlite3.sql文件,并且你已经安装了SQLite应用,Django会首先执行 sql/person.sqlite3.sql的内容,其次才是sql/person.sql。
译者:飞龙,原文:Providing initial data。
本文以 CC BY-NC-SA 3.0 协议发布,转载请保留做者署名和文章出处。
Django 文档协做翻译小组人手紧缺,有兴趣的朋友能够加入咱们,彻底公益性质。交流群:467338606。
若是以为文章还不错,能够扫描下面的二维码来打赏我。