35

我目前正在使用 Django 进化来管理我的产品的数据库进化。它并不完美，但我已经学会忍受它的缺陷。例如，在移出新模式之前，我总是必须复制我的生产数据库进行测试，因为“evolve”命令不能总是演化在几次小型迁移中更改的数据库（在测试中我做了 A->B->C，但 A->C 不会正确进化。）

South会解决所有这些问题吗？学习新工具值得付出努力吗？

4

1 回答 1

52

我刚开始使用 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以实际提交对数据库的更改

编辑—— 为了澄清下面的评论，核心贡献者正式投票决定不包含在 1.2 版中。部分原因是《南方》的作者要求不要将其包括在内。尽管如此，South 还是有很多社区支持，一些可重复使用的应用程序制造商开始在他们的应用程序中包含 South 迁移。

编辑#2——我做了一些更新以反映当前 South 主干版本的新 manage.py 命令结构。“startmigration”已根据您的操作分为“schemamigration”和“datamigration”。

于 2009-10-19T21:12:44.530 回答