我目前正在使用 Django 进化来管理我的产品的数据库进化。它并不完美，但我已经学会忍受它的缺陷。例如，在移出新模式之前，我总是必须复制我的生产数据库进行测试，因为“evolve”命令不能总是演化在几次小型迁移中更改的数据库（在测试中我做了 A->B->C，但 A->C 不会正确进化。）
South 会解决所有这些问题吗？学习新工具值得付出努力吗？
【问题讨论】：
标签： django django-south django-evolution
我刚开始使用 South，我 100% 都在使用它。它也是少数仍在积极开发中的产品之一。
South 应该能够正确处理您在上面描述的问题。对于数据库的每次更改，它都会创建一个具有 2 种方法“向前”和“向后”的文件。这是一个自动生成的迁移示例：
# > manage.py schemamigration issuetracker added-status-field --auto
# 0004_added-status-field.py
class Migration:
def forwards(self, orm):
# Adding field 'Issue.status'
db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])
def backwards(self, orm):
# Deleting field 'Issue.status'
db.delete_column('issuetracker_issue', 'status')
关于它的一些好处....
South 允许您回滚到特定迁移 # 如果您愿意的话
如果您的生产站点在迁移 0002 并且您的 SVN 提交在 0004，South 将执行 0003 然后 0004 以使生产数据库加速。
如果您自己进行了更改，则可以告诉 South 运行“假”迁移。通常，迁移系统会很麻烦，但这使得灵活控制数据库变得非常容易。
manage.py migrate [appname] --fake
如果您需要进行一些自定义操作，例如将一列中的数据复制到另一列，因为迁移文件只是 python 文件，因此很容易修改前进/后退函数。
在部署应用程序后迁移到 South 相当容易。最新的 0.6 版本实际上包含了一个命令。
manage.py convert_ to _south [appname]
当然，我怎么会忘记，我最喜欢的功能是自动生成迁移文件
manage.py schemamigration [appname] [description] --auto
我想我应该为我在开始使用 South 时所犯的错误添加一些提示。并非所有内容都是 100% 直观的。
在开发数据库上运行 convert_to_south 命令后，不要忘记在生产数据库上运行 migrate --fake，否则 South 会认为它已经过时了。
如果您要创建新应用，请使用 --initial 标志
停止使用 manage.py syncdb。真的。
编辑模型是一个 3 步过程 --
1.) 保存模型更改
2.) 运行schemamigration --auto
3.) 运行 migrate 以实际将更改提交到数据库
编辑 -- 为了澄清下面的 cmets，核心贡献者正式投票决定不将 South 包含在 1.2 版中。部分原因是《南方》的作者要求不要将其包括在内。尽管如此，South 还是有很多社区支持，一些可重复使用的应用程序制造商开始在他们的应用程序中包含 South 迁移。
编辑 #2 -- 我做了一些更新，以反映来自当前 South 主干版本的新 manage.py 命令结构。 “startmigration”已根据您的操作分为“schemamigration”和“datamigration”。
【讨论】：