Django 数据表更改

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

Django 1.7.x和后来的版本：

Django1.7.x及以后的版本继承了South的功能，在修改models.py了后运行：

python manage.py makemigrations
python manage.py migrate

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

Django1.6.x及以前：

写过Django项目的同学，必然后遇到这个问题：
在Django1.6及以前的版本中，我们测试，当代县model要改，怎么办？
我们修改了models.py之后，我们运行：

python manage.py syncdb

这句话将我们在models.py中新加的类创建响应的表

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

如果在原来的类上增加字段或者删除字段，可以参考这个命令

python manage.py sql appname

给出得 SQL语句，然后自己手动到数据库执行SQL，但是这样非常容易出错

Django 的第三方app south 就是专门做数据库表结构自动迁移工作JacobKaplan-Moss 曾做过一次调查，South名列最受欢迎的而第三方app，事实上，他现在已经成为Django数据库表迁移标准，很多第三方app都会带South migratins脚本，Django1.7中继承了South的功能。

1、安装South

student@student-VirtualBox:~$ sudo pip install 
[sudo] password for student: 
student@student-VirtualBox:~$ sudo pip install South
[sudo] password for student: 
Downloading/unpacking South
  Downloading South-1.0.2.tar.gz (96Kb): 96Kb downloaded
  Running setup.py egg_info for package South
    
Installing collected packages: South
  Running setup.py install for South
    
Successfully installed South
Cleaning up...
student@student-VirtualBox:~$ 

2、使用方法
一个好的程序使用起来必定是简单的，South和它的宗旨一样，使用简单，只需要简单几步，针对已经建好的model和创建完表的应用

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

# 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）的历史记录

$ 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来管理：

$ python manage.py convert_to_south blog

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

注：如果 blog 这个 app 之前就创建过相关的表，可以用下面的来“假装”用 South 创建（伪创建，在改动 models.py 之前运行这个）

python manage.py migrate blog --fake

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

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

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

$ python manage.py schemamigration blog --auto

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

$ 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好处就是可以随时恢复到之前的一个版本，比如我们想要回到最开始的那个版本：

> 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

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

####### django1.7后集成south的使用方法
对于app间有依赖关系的初始化，先在settings中将其他app注掉，同步主表，然后再打开其他app同步
1、初始部署代码，初始化数据库，建表但没有对app注册migratie

python manage.py makemigrations
python manage.py migrate
# 此时字段并不能被migrate检测到，无法变更字段，
此命令作为整个工程初始化数据库是使用，主要用于
初始化User等标准库

2、对已有数据库的app转化为migrate

python manage.py makemigrations app_name
python manage.py migrate app_name --fake-inital
# 即可初始化。之后app中字段变动有以下两中方式修改

# a) 修改所有注册过migrate的app
python manage.py makemigrations
python manage.py migrate

# b)单独修改APP
python manage.py makemigrations app_name
python manage.py migrate  app_name

3.新增app,还未创建数据库的

python manage.py makemigrations app_name
python manage.py migrate  app_name

4.对于工具类app的model，不需要修改，则不需要注册migrate