Django 数据表更改

Django 数据表更改

« Django 开发内容管理系统（第四天）

Django 后台 »

 

咱们设计数据库的时候，早期设计完后，后期会发现不完善，要对数据表进行更改，这时候就要用到本节的知识。

Django 1.7.x 和后来的版本：

Django 1.7.x 及之后的版本集成了 South 的功能，在修改models.py了后运行：

1 2	python manage.py makemigrations python manage.py migrate

这两行命令就会对咱们的models.py 进行检测，自动发现须要更改的，应用到数据库中去。

Django 1.6.x 及之前：

写过Django项目的同窗，必然会遇到这个问题：

在Django 1.6以及之前的版本中，咱们测试，当发现model要改，怎么办？

 

咱们修改了 models.py 以后，咱们运行：

1	python manage.py syncdb

这句话只会将咱们在 models.py 中新加的类建立相应的表。

对于原来有的，如今删除了的类，Django 会询问是否要删除数据库中已经存在的相关数据表。

 

若是在原来的类上增长字段或者删除字段，能够参考这个命令：

1	python manage.py sql appname

给出的SQL语句，而后本身手动到数据库执行 SQL 。可是这样很是容易出错！

Django 的第三方 app South 就是专门作数据库表结构自动迁移工做，Jacob Kaplan-Moss 曾作过一次调查，South 名列最受欢迎的第三方 app。事实上，它如今已经俨然成为 Django 事实上的数据库表迁移标准，不少第三方 app 都会带 South migrations 脚本，Django 1.7 中集成了 South 的功能。

 

1, 安装South

1	( sudo ) pip  install  South

 

2. 使用方法

一个好的程序使用起来一定是简单的，South和它的宗旨同样，使用简单。只须要简单几步，针对已经建好model和建立完表的应用。

 

把south加入到settings.py中的INSTALL_APPS中

1 2 3 4 5 6 7 8 9 10 11 12

# Application definition INSTALLED_APPS  =  (      'django.contrib.admin' ,      'django.contrib.auth' ,      'django.contrib.contenttypes' ,      'django.contrib.sessions' ,      'django.contrib.messages' ,      'django.contrib.staticfiles' ,        'blog' ,      'south' , )

修改好后运行一次 python manage.py syncdb，Django会新建一个 south_migrationhistory 表，用来记录数据表更改(Migration)的历史纪录。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

$ python manage.py syncdb Syncing... Creating tables ... Creating table south_migrationhistory Installing custom SQL ... Installing indexes ... No fixtures found.   Synced:   > django.contrib.admin   > django.contrib.auth   > django.contrib.contenttypes   > django.contrib.sessions   > django.contrib.messages   > django.contrib.staticfiles   > blog   > south   Not synced (use migrations):

 

若是要把以前建好的好比 blog 这个 app 使用 South 来管理：

1	$ python manage.py convert_to_south blog

你会发现blog文件夹中多了一个 migrations 目录，里面有一个 0001_initial.py 文件。

 

注：若是 blog 这个 app 以前就建立过相关的表，能够用下面的来“伪装”用 South 建立（伪建立，在改动 models.py 以前运行这个）

1	python manage.py migrate blog --fake

意思是这个表我之前已经建好了，用 South 只是纪一下这个建立记录，下次 migrate 的时候没必要再建立了。

原理就是 south_migrationhistory 中记录下了 models.py 的修改的历史，下次再修改时会和最近一次记录比较，发现改变了什么，而后生成相应的对应文件，最终执行相应的 SQL 更改原有的数据表。

 

接着，当你对 Blog.models 作任何修改后，只要执行：

1	$ python manage.py schemamigration blog --auto

South就会帮助咱们找出哪些地方作了修改，若是你新增的数据表没有给default值，而且没有设置null=True, south会问你一些问题，由于新增的column对于原来的旧的数据不能为Null的话就得有一个值。顺利的话，在migrations文件夹下会产生一个0002_add_mobile_column.py，可是这一步并无真正修改数据库的表，咱们须要执行 python manage.py migrate ：

1 2 3 4 5 6

$ python manage.py migrate Running migrations  for  blog:   - Migrating forwards to 0002_add_mobile_column.   > blog:0002_add_mobile_column   - Loading initial data  for  blog. No fixtures found.

这样所作的更改就写入到了数据库中了。

 

恢复到之前

South好处就是能够随时恢复到以前的一个版本，好比咱们想要回到最开始的那个版本：

1 2 3 4 5

> python manage.py migrate blog 0001   - Soft matched migration 0001 to 0001_initial. Running migrations  for  blog:   - Migrating backwards to just after 0001_initial.   < blog:0002_add_mobile_column

这样就搞定了，数据库就恢复到之前了，比你手动更改要方便太多了。