By
澳门新葡萄京所有网站,Calabash

django提供syncdb命令,用于从models自动生成数据库。但在models构造调换后,syncdb并不只怕活动达成数据库的换代。South组件正是为了缓和该难点而现身的。
上面简要介绍一下South的朝气蓬勃对最遍布用法,更详尽的选取办法见South的法定手册。

咱俩设计数据库的时候,开始时期规划完后,中期开采残破,要对数据表举行改善,这个时候就要用到这届的学识。

利用South以前铭记:请你必定要相信他的力量,遗弃对她的不相信赖感。因为South给人的第意气风发印象正是近乎各样操作都在抛十分。

假使大家创设了三个名称叫southtut的app

Django 1.7.x和新兴的版本:

Django1.7.x及事后的本子世袭了South的功力,在改变models.py了后运转:

python manage.py makemigrations
python manage.py migrate

这两行命令就能对大家的models.py实行检查实验,自动发掘须求修正的,应用到数据库中去。

South概述

生成最早化数据库的south脚本。允许上述命令后就要对于的app目录下生成
migrations目录,south的数据库迁移脚本即保存在该目录。
./manage.py schemamigration southtut –initial

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

*
针对django自带的syncdb同步models和数据库的缺点开荒的数据迁移工具,能够充当syncdb的取代,South能够检查实验对models的改换并一齐到数码库.

 
在所用south后,syncdb命令不会为利用south托管的app生成数据库。migrate命令用于施行south的数据库迁移脚本,
完结数据库改良。在这间举办的操作是为southtut创设连锁的数额库表。不带app名字时,将对project中的全部app举办migrate操
作。
./manage.py migrate southtut

South基本用法

 
在众多选择场景中,大家已经用syncdb将数据库给成立好了。这时运维方面包车型地铁migrate命令将会提示相关表已经存在,命令实行停业。这时大家必要报告south要求跳过一些migrate操作。上面的指令将报告south,系统现已实行过了0001号数据库迁移脚本。
./manage.py migrate southtut 0001 –fake

*
安装完South之后,要在django项目中使用South,先要将South作为八个App导入项目,所以设置INSTALL_APP添加south

 
接下去大家对models进行了好几改变,改进后增减了某个字段。
该命令将自动生成数据库的搬迁脚本。在migrations目录下能够见见新增了文本0002_xxx.py,该文件就是这次models改造的数据库升级脚本。张开文件后可知到此中有一个类Migration,类中有多个艺术forwards和backwards。那多个情势分别完成数据库
进级和平构和会议滚时对数据库的操作,具体指令的意义参照他事他说加以侦查south的数据库API。
./manage.py schemamigration southtut –auto

* 第3回利用South(对于已存在的品种转变South见下一步的牵线)

 
行使models的转移到数据库
./manage.py migrate southtut

    python manage.py schemamigration youappname --initial  # youappname目录下面创建一个migrations的子目录(注意!!就算有多个app,也只要initial一个就可以)

    python manage.py syncdb                                #初始化数据表等


    #以后每次对models更改后,可以运行以下两条命令同步到数据库

    python manage.py schemamigration youappname --auto     #检测对models的更改

    python manage.py migrate youappnam  #将更改反应到数据库(如果出现表已存在的错误,后面加 --fake)

摘自 python.cn

迁移到South

*
对于三个已存在的门类(定义了models,创造了相应的数据库,保存了响应的数额),这个时候想要使用South代替原先的syncdb只须要部分归纳的步调:

* 相似须求以往INSTALL_应用软件里面增加south,然后

    python manage.py syncdb  #syncdb已经被South更改,用来创建south_migrationhistory表

    python manage.py convert_to_south youappname #在youappname目录下面创建migrations目录以及第一次迁移需要的0001_initial.py文件

* 以往在这里个体系中就足以健康使用South了

South同步原理

* 对应每一遍models的改换推行schemamigration后会在migrations目录下面生成对应本次改动的py文件(South称之为
migrate),文件名形如0002_autodel_field_notes_create_user.py,同步数据库的时候会相继(文件名
ASCII排序)试行这一个py文件,文件里带有二个Migration的类,里面有四个主意forwards和backwards,将改成同步到数据库会
推行forwards方法,数据库操作失利会调用backwards实现rollback,South还提供了近乎回溯的机能。

You can also specify a specific migration to migrate:

    * python manage.py migrate 0002_autodel_field_notes_create_user.py

Note that, if the system has already migrated past the specified migration, it will roll back to it instead. If you want to migrate all the way back, specify the special migration name zero:

    * python manage.py migrate zero

广阔难题

  1. 累计和删除字段时或许会须要输入 default
    value(django里面models里面包车型客车不菲字段暗中同意皆以null=False)
        
    对于加多字段,输入的暗中同意值必得和models定义的连串相配,否则同步数据库的时候会报错
        
    对于删除字段的状态,能够私行输入二个value而不管字段的暗中同意类型,能够兑现删除,不过并不可取,具体原因能够敬重South的落实机制(rollback到删除字段之前会失败)。

  2. 杀手锏
        
    假如South在一块数据库的长河中冒出谬误,则migrations目录下直面应此番更换的python文件不会被实践,能够运作python
    manage.py migrate
    –list查看未有执行的py文件,文件名后面未有*代表该公文对应的更改未有影响到数据库,只需删除掉那个有标题标migrate,参照错误提醒校订models再同台就可以,也足以直接更换对应的py文件修复错误。

  3. 假如出现就疑似 “_mysql_exceptions.OperationalError: (1050,…”
    的错误:
    (1卡塔尔(قطر‎或者是先syncdb然后又–initial了,顺序不可能颠倒
    (2卡塔尔大概多次运作了–initial,记住不管有多少app,开端化只要对内部贰个app实行就能够了
    (3State of Qatar现身这些张冠李戴也可能有补救方法:manage.py migrate youappnam –fake
    (加上fake运营三遍,就常常了,何况现在绝不再加fake参数)


(2013-09-20 修改了生机勃勃部分内容 –静夜思卡塔尔