目前使用的是Django的“进化论”,“南方”是否更好,值得转换?

我刚开始使用South,100%的销量。它也是少数仍在积极发展中的国家之一。

South应该能够正确处理您上面描述的问题。对于数据库的每次更改,它都会创建一个文件,该文件有两个方法“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')

关于它的一些美好的事情…

• 如果您愿意,South允许您回滚到特定的迁移

• 如果您的生产站点位于迁移0002上,而您的SVN提交位于0004上,那么South将执行0003,然后执行0004,以使生产数据库达到最快速度。

• 如果你自己进行了改变,你可以告诉南方进行一次“假”移民。通常,迁移系统会发出嘶嘶声,但这使得对数据库的灵活控制变得非常容易。

  manage.py migrate [appname] --fake

• 如果需要进行自定义操作,例如将一列中的数据复制到另一列,因为迁移文件只是Python文件,所以很容易修改前向/后向功能。

• 在部署了应用程序之后迁移到南方是相当容易的。最新版本0.6实际上包含了一个命令。

  manage.py convert_ to _south [appname]

• 当然,我怎么能忘记,我最喜欢的功能是自动生成迁移文件

  manage.py schemamigration [appname] [description] --auto

高查斯

我想我应该为我在开始南下时犯的错误添加一些提示。并非所有事情都是100%直观的。

• 在开发数据库上运行convert-to-south命令后,不要忘记运行 migrate --fake 在你的生产数据库上,否则南方会认为它已经过时了。

• 如果要创建新应用程序,请使用 --initial 旗帜

• 停止使用manage.py syncdb。真的?

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

  1.)保存模型更改

  2)运行 schemamigration --auto

  3.)运行 migrate 将更改实际提交到数据库

编辑—— 为了澄清以下评论,South由核心投稿人正式投票决定不包含在1.2版中。这在一定程度上是因为《南方》的作者要求将其包括在内。尽管如此,仍然有很多社区对South的支持,一些可重用的应用程序制造商开始在他们的应用程序中加入South Migration。

编辑2 我做了一些更新,以反映来自当前主干版south的新manage.py命令结构。”StartMigration“已拆分为“SchemaMigration”和“DataMigration”,具体取决于您正在执行的操作。