内容简介：随着项目进度推进，业务的流程更加完善，我的理解也更加深入。逐渐发现早期一些数据库表和APP的关系，不是那么的合理和有序。相关联的一些业务逻辑的表，不同业务层面的表，应该合理的、有序的、科学的分属于不同的APP。为了实现这份合理，就需要对现有的表进行数据迁移。Django的表关系，不能直接通过数据库一行命令修改表的名称来更新，本身Django内部的数据库表State同样也得跟着一起维护。加上现在涉及到的一些外键，变得更加的麻烦。全网资料不多，参考了迁移思路是先生成新的Model，然后在 Django Stat
随着项目进度推进，业务的流程更加完善，我的理解也更加深入。逐渐发现早期一些数据库表和APP的关系，不是那么的合理和有序。相关联的一些业务逻辑的表，不同业务层面的表，应该合理的、有序的、科学的分属于不同的APP。为了实现这份合理，就需要对现有的表进行数据迁移。
Django的表关系，不能直接通过数据库一行命令修改表的名称来更新，本身Django内部的数据库表State同样也得跟着一起维护。加上现在涉及到的一些外键，变得更加的麻烦。全网资料不多，参考了 Django的相关Ticket 和 这份资料 ，成功的在生产环境实现了Model在不同App之间的迁移。
迁移思路是先生成新的Model，然后在 Django State 层面将逻辑指向新的Model，不改动数据库表结构。再修改数据库结构，将旧表重命名成新表。最后Django State层面删除旧表，数据库表结构不改动。完成了Model迁移并且不损失数据。 单个Model迁移的步骤如下。多个Model需要迁移，请按顺序逐个操作。数据库表变动是高风险操作，务必小心谨慎。
0. 创建数据库备份，这是翻车之后的救命稻草
1. 将旧的Model代码复制到新的App下的 models.py
，将全部的使用旧Model的外键更新成新的Model
2. 执行
python manage.py makemigrations
3. 编辑 migration 文件，将自动生成的 operations
部分按照如下修改：
operations=[
migrations.SeparateDatabaseAndState(
database_operations=None,
state_operations=[
# 自动生成的 operations 复制到这里。
]
),
]
4. 删除旧Model的代码，执行
python manage.py makemigrations
5. 编辑 migration 文件，两个操作：
- 将上一步全部的新生成的 migration 文件添加到 dependencies
dependencies = [
# 将上一步全部的新生成的 migration 文件添加到这里
]
-
将自动生成的
operations部分按照如下修改
operations = [
migrations.SeparateDatabaseAndState(
database_operations=[
migrations.AlterModelTable('mymodel', 'new_app_mymodel'),
# 假设将 Account 这个 Model 从 hello 这个 App 移动到 world 下，应该修改成
# migrations.AlterModelTable('account', 'world_account'),
],
state_operations=[
# 自动生成的 operations 复制到这里。
]
),
]
6. 检查上面的流程，知道自己每一步干的什么，没有问题的话，执行
python manage.py migrate
检查 and 测试。没有问题，Model迁移成功。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 银行核心海量数据无损迁移：TDSQL数据库多源异构迁移方案
- 再无需从头训练迁移学习模型！亚马逊开源迁移学习数据库 Xfer
- Spring Cloud Alibaba迁移指南（一）：一行代码从 Hystrix 迁移到 Sentinel
- Spring Cloud Alibaba迁移指南1：零代码从Eureka迁移到Nacos 原 荐
- Spring Cloud Alibaba迁移指南2：一行代码从Hystrix迁移到Sentinel 原 荐
- 数据迁移的套路
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
