【问题标题】:South migration: delete all migration files (00*_*) and start from 0001, while keeping the original data南迁移:删除所有迁移文件(00*_*)并从0001开始,同时保留原始数据
【发布时间】:2015-11-11 12:44:02
【问题描述】:

我正在使用 Django 开发 Web 系统,它们部署在 Heroku 上。系统投入生产后,必须保留所有数据库数据和迁移文件(即 00*_* 文件)。以下是我执行数据库迁移和部署的过程:

  1. 对于第一次部署,在本地执行manage.py makemigrations并推送到Heroku。

  2. 在 Heroku 上执行 manage.py migrate

如果稍后更改模型:

  1. 在本地执行 makemigrations 并推送到 Heroku。

  2. 在 Heroku 上执行 migrate

如果模型发生变化,则重复第 3 步和第 4 步。

随着系统的发展,迁移文件越来越多。我想知道:成功迁移和部署后,我可以删除所有迁移文件并像一个新文件一样开始吗?那就是:

  1. 对于第一次部署,在本地执行makemigration并推送到Heroku。

  2. 在 Heroku 上执行 migrate

  3. 删除所有本地迁移文件。

  4. 在本地执行makemigrations 以创建看似启动的迁移文件。

改变模型:

  1. 在本地执行 makemigration 并推送到 Heroku。

  2. 在 Heroku 上执行 migrate

如果模型发生变化,则重复第 3 步到第 6 步。

上述程序正确吗?

【问题讨论】:

    标签: heroku deployment migration django-south


    【解决方案1】:

    对于您的每个应用:

    1) 假装回滚所有现有迁移:

    ./manage.py migrate app zero --fake
    

    zero 参数表示我们回滚到第一次迁移。您可以通过运行./manage.py migrate app --list 来确认所有迁移都已回滚。 --fake 选项表明我们不应实际运行迁移,但仍将迁移标记为已运行:https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake

    2)。删除迁移文件

    git rm app/migrations/*
    

    3) 创建一个新的迁移文件

    ./manage.py makemigrations app
    

    4) 假装运行新的迁移

    ./manage.py migrate app --fake
    

    与 1) 一样,步骤 4) 并不实际运行迁移。

    编辑:添加了一些解释并修复了 zero 参数。

    【讨论】:

    • 非常感谢。请您详细说明第 1 步和第 4 步吗?它们是什么意思?
    • 知道了。最后一个问题:如果我需要更改模型,顺序是什么? 1(远程)--> 2(本地)--> 更改应用程序的模型--> 3(本地)--> 推送到远程--> 4(远程)。它是否正确?我是否需要在第 4 步删除“--fake”才能实际运行迁移?
    • 我建议您像往常一样在 1) 之前对模型进行所有必要的修改。只需在本地运行 makemigration 并在 heroku 上迁移。
    • 可能值得注意的是命令1和4需要在服务器上运行。我的开发机器上一切正常,但部署后 django_migrations 表没有反映更改。
    猜你喜欢
    • 1970-01-01
    • 2014-12-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-05-21
    • 1970-01-01
    • 2016-11-27
    • 2020-11-21
    相关资源
    最近更新 更多