推荐学习书目 Learn Python the Hard Way Python Sites PyPI - Python Package Index http://diveintopython.org/toc/index.html Pocoo 值得关注的项目 PyPy Celery Jinja2 Read the Docs gevent pyenv virtualenv Stackless Python Beautiful Soup 结巴中文分词 Green Unicorn Sentry Shovel Pyflakes pytest Python 编程 pep8 Checker Styles PEP 8 Google Python Style Guide Code Style from The Hitchhiker's Guide
这是一个创建于 3226 天前的主题，其中的信息可能已经有所发展或是发生改变。
一开始用 django-admin startapp 建了一个，随着开发，发现其中一个地方功能比较多，适合分出来做成另一个独立的 app ，请问如何将原有的这个拆出来呢？
views urls 都比较好搞，主要问题是 models ，如果移动了位置，会产生新的 migrations ，但其实数据的表结构是没有变的……
第 1 条附言 2016-12-14 14:21:13 +08:00
已解决。
谢谢大家，已经解决，分享一下方案。
0.将 app 分离出来，重构代码
1.用 db_table 指定和原来的表名字相同
2.makemigrations
3.用--fake 执行 migrate ， fake 过程中中遇到引用这个表的外键的时候，问是否决定删除相关 table ， yes 就可以，因为这个时候依然是在 fake
谢谢大家，已经解决，分享一下方案。
0.将 app 分离出来，重构代码
1.用 db_table 指定和原来的表名字相同
2.makemigrations
3.用--fake 执行 migrate ， fake 过程中中遇到引用这个表的外键的时候，问是否决定删除相关 table ， yes 就可以，因为这个时候依然是在 fake
14 条回复 2018-06-13 09:00:45 +08:00
 | 1 wyntergreg 2016-12-14 09:14:53 +08:00  1 models 不需要移动的， import 就好 |
 | 2 scriptB0y OP @wyntergreg 但是有个 model 太大了，里面的东西也是原来的 app 相关的，比较想拆出来 |
 | 3 wizardoz 2016-12-14 09:20:05 +08:00 1 如果移动了位置，会产生新的 migrations ，但其实数据的表结构是没有变的…… ============================================= ./manage.py migrate --fake --fake 就是让它以为已经 migrate 了,但是不真正的去操作数据库. |
 | 4 tamama 2016-12-14 09:25:21 +08:00 1 移动 model 产生新的 migration ，会导致数据库的表名也改变。可以在新的 app model 里边明确指定表名为原来 model 的表名就行了 |
| 7 wyntergreg 2016-12-14 09:57:39 +08:00 @scriptB0y make 的时候如果出错，可以看是什么错，直接改对应的 migrate 文件，这种做法可以止血，但治标不治本 |
| 8 wyntergreg 2016-12-14 10:04:36 +08:00 1 @scriptB0y 建议把 models 和 app 分开， models 直接放到一个 common_app 里边，业务逻辑 app 都分出去，这样做清静，不过貌似不符合 django 推荐的规范:) |
| 9 scriptB0y OP @wyntergreg 也是一种好办法 ：） |
 | 10 qwer1234asdf 2016-12-14 12:22:22 +08:00 1 要不就 model 使用第三方 plugin 监控 history 咯 |
 | 11 zeroten 2016-12-14 13:28:45 +08:00 1 定义 db_table 也没用么？ |
 | 13 sallowdish 2016-12-14 17:36:21 +08:00 只想一句，重前把 unittest 好 |
 | 14 dcoder 2018-06-13 09:00:45 +08:00 @scriptB0y @wyntergreg 我也感觉把 "models 直接放到一个 common_app" 里最清静啊，实际用起来有什么问题没? 我想的方案, 兼顾 model migration 的方便, 和以后抽象出 reusable Django app. common_app 里定义所有的 models, 注意这里 common_app.models 是个 python 包 (带 __init__ 的文件夹). 然后各种业务逻辑，可以自由定义和重构在各个 empty-model 的 app 中, 也就是还是当 Django app 来些，只是 models.py 是空的, 真正的 models 还是从 common_app.models 里 import 的 (你也可以事先 import 到这个 app 的 empty models.py 中). 这样的话，各个业务逻辑的 app，就随便重构, 移动, 修改了. 万一哪天真想抽象出一个 reusable Django app, 可以 export 到另外的 project/server 中. 再自定义 migration 脚本, 把 common_app 中的 model 和 model data 导出来到这个 reusable app 中. |
Select Language