我像往常一样将<project>/<app>/migrations
文件夹添加到版本控制中进行部署。因为最近我还使用了django-auditlog,它在<project>/env/Lib/site-packages/auditlog/migrations
中创建了自己的迁移。这些迁移适用于我自己的迁移。所以我想知道:我是否也应该将它们添加到VCS并部署它们?我应该如何处理插件创建的迁移?
0
A
回答
0
不可以。您不应该部署这些迁移。一般而言,您不应该部署任何第三方迁移。
原因很简单。第三方软件包在其migrations
目录中进行了初始迁移。每次创建依赖于第三方软件包的迁移时,此迁移都将存在于您的应用的migrations
目录中(不在包之内)。
所以,当你第一次部署你的代码和你的服务器上运行pip install -r requirements.txt
,那么所有第三方软件包将被安装,当你做./manage.py migrate
那么Django会看你的INSTALLED_APPS
和执行所有迁移为每一个在此列表中。
与Django本身一样,任何第三方软件包也会发生同样的情况。假设你在requirements.txt
文件中只有Django==1.10.6
。当你将它部署到服务器并执行pip install -r requirements.txt
,时,那么你的数据库将被所有内置的Django特定表(即auth
,sessions
,contenttypes
等)“填满”,并在INSTALLED_APPS
中启用设定清单。
唯一的一个,你应该部署是项目目录(requirements.txt
,manage.py
,robots.txt
等)下的一切,而不是你的第三方应用程序可以活多久你的项目中(下.virtualenv
目录,可能)或在单独.virtualenv
目录在您的项目之外。
与你的问题类似的是node_modules
nodejs。 node_modules
目录从未部署到VCS(因为它的大小可能相当大),而只有package.json
,因为知道项目需要哪些依赖关系(package.json
/requirements.txt
),那么您的项目可以从零“重建”自己。
相关问题
- 1. 我应该为新创建的迁移推送schema.rb文件
- 2. 我应该使用迁移来创建文件夹吗?
- 3. 我应该如何处理软件包?
- 4. 我应该如何处理Button事件?
- 5. 我应该如何创建我的GUID?
- 6. 我应该处理
- 7. 如何处理自动迁移
- 8. 我该如何处理使用Git的插件回购?
- 9. 我该如何处理插件中缺失的图像?
- 10. 我应该如何处理sqlite错误?
- 11. 我应该迁移到msqli吗?
- 12. 为管理员用户创建迁移
- 13. 我应该为未使用的表创建表删除迁移吗?
- 14. 如何使用Grails和数据库迁移插件执行插件迁移?
- 15. 从处理迁移到processing.js
- 16. 如何创建迁移以将初始数据插入表中?
- 17. (StaleElementException:Selenium)我该如何处理?
- 18. NullReferenceException,我该如何处理?
- 19. 我应该如何处理用手卷DAL创建复合实体?
- 20. 当我使用Moodle创建PHP课程时,应该如何处理数据库?
- 21. 我应该如何使用批处理脚本来创建其他脚本?
- 22. 如何创建将填充我的菜单的迁移
- 23. Capistrano部署rails应用程序 - 如何处理长迁移?
- 24. 如何从TortiseSVN迁移到Eclipse插件来管理已建立的SVN项目
- 25. 我应该如何处理J2ME中的关键事件?
- 26. inotify - 我应该如何处理完整的事件队列?
- 27. 我应该如何处理Vuex中的事件?
- 28. 我应该创建什么样的VS 2010插件/扩展?
- 29. Grails如何处理安全性,为什么我应该使用插件?
- 30. 从应用程序创建迁移
感谢您的详细解答。这对我来说似乎是有道理的,但是您能否补充一点澄清:为什么我自己的迁移会有所不同?大概我们不相信Django可以在部署时始终正确地重建它们,所以它们应该受版本控制。然后,我们为什么信任Django的第三方应用迁移功能? – texnic
您可能(或不是)版本控制您的应用程序的迁移,但不是第三方的。因为第三方应用程序存在于您的虚拟环境中(在'site-packages'目录下)。你不需要版本控制这个目录。在部署你的项目后,你运行'pip install -r requirements.txt'(注意这个文件下的每个应用都有一个版本号),并且安装了所有的第三方软件包(以及它们的任何潜在的迁移)。所以,你确定每个第三方都会在你的项目中应用正确的迁移。这是否为你澄清? –
不:)这是有道理的,这也是我目前的做法。但是我错过了为什么我可以相信在安装第三方应用程序时会生成和应用正确的迁移,而不是在部署我自己的应用程序时。如果我理解正确,通过VCS部署我自己的迁移的想法是迁移不保证以我想用'manage.py makemigrations'创建的方式创建,所以我希望能够提前测试它们。我可以想象,例如管理网站的迁移生成是非常明确的和可靠的。这同样适用于第三方应用程序吗?这里的差异让我感到不安。 – texnic