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 |
这样就搞定了,数据库就恢复到以前了,比你手动更改要方便太多了。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 智能桌面机器人:用.NET IoT库控制舵机并多方法播放表情
· Linux glibc自带哈希表的用例及性能测试
· 深入理解 Mybatis 分库分表执行原理
· 如何打造一个高并发系统?
· .NET Core GC压缩(compact_phase)底层原理浅谈
· 手把手教你在本地部署DeepSeek R1,搭建web-ui ,建议收藏!
· 新年开篇:在本地部署DeepSeek大模型实现联网增强的AI应用
· Janus Pro:DeepSeek 开源革新,多模态 AI 的未来
· 互联网不景气了那就玩玩嵌入式吧,用纯.NET开发并制作一个智能桌面机器人(三):用.NET IoT库
· 【非技术】说说2024年我都干了些啥
2016-10-29 linux 常用命令
2016-10-29 quickstart.sh
2014-10-29 linux install nodejs
2014-10-29 logstash启动脚本
2014-10-29 退出linux控制台不退出启动应用命令
2014-10-29 安装logstash+kibana+elasticsearch+redis搭建集中式日志分析平台
2012-10-29 web harvesst