目前使用Django"Evolution",是"南方"更好,值得转换?

Mik*_*keN 35 django django-south django-evolution

我目前正在使用Django evolutions来管理我的产品的数据库演变.它并不完美,但我学会了忍受它的缺陷.例如,在移出新模式之前,我总是必须复制我的生产数据库进行测试,因为"evolve"命令不能总是演变一个在几次小迁移中改变的数据库(在测试中我做了A-> B-> C,但A-> C不会正确演变.)

南方会解决所有这些问题吗?是否值得学习新工具的努力?

T. *_*one 52

我刚刚开始使用South,我100%在它上面销售.它也是为数不多的仍处于非常活跃的发展之一.

南方应该能够妥善处理你上面描述的问题.对于db的每次更改,它都会创建一个文件,其中包含两个方法"foward"和"backwards".以下是自动生成迁移的示例:

# > 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')
Run Code Online (Sandbox Code Playgroud)

一些关于它的好东西......

  • 如果您愿意,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


陷阱

我想我应该补充一些关于我在南方开始时犯的错误的提示.并非一切都是100%直观的.

  • 在开发数据库上运行convert_to_south命令后,不要忘记migrate --fake在生产数据库上运行,否则South会认为它已过时.

  • 如果您要创建新应用,则使用该--initial标志

  • 停止使用manage.py syncdb.真.

  • 编辑模型是一个三步过程 -

    1.)保存模型更改

    2.)跑 schemamigration --auto

    3.)运行migrate以实际提交对数据库的更改

编辑 - 为了澄清下面的评论,South被核心贡献者正式投票,不包括在版本1.2中.这部分是因为南方的作者要求它尚未包括在内.即便如此,南方还有很多社区支持,一些可重复使用的应用程序制造商开始将南方迁移纳入他们的应用程序.

编辑#2 -我做了一些更新,以反映当前主干版本的South的新manage.py命令结构.根据你正在做的事情,"startmigration"被分为"schemamigration"和"datamigration".

  • @Adam Nelson还未决定.您链接到的Wiki页面是提案列表.核心开发人员目前正在对提案进行投票(以获得对他们的全面支持),我认为目前的意见趋向于不包括南方(尚未).南方维护者表示他不希望在这一点上与Django的发布时间表挂钩. (4认同)