我想在我的django进程启动时运行一些环境检查,并在发生错误时大声死亡。我认为数据库的编码不正确,或者机器有我们不支持的python版本。
我宁愿我们的团队面临他们必须解决的致命错误,而不是忽视它。
我写这些支票很好,但我很好奇放在哪里最合适的地方。如何让它们作为django启动过程的一部分执行?我以为可能有一个信号我也可以听,但我在文档中找不到相关的信号。
答案 0 :(得分:4)
如果您不想使用设置模块,请尝试项目的__init__.py
。
答案 1 :(得分:4)
如果您想检查系统是否已正确安装,我认为您应该编写own admin command并将其作为安装后检查运行。
我认为不值得检查python版本是否经常正确安装,特别是如果您在共享主机上安装django应用程序。我的应用程序托管在alwaysdata,他们每小时重启一次FastCgi进程。这些检查会对应用程序响应时间产生影响。
答案 2 :(得分:3)
我会把它们放在settings.py中。在过去,我已经进行了如下系统检查:
try:
from local_settings import *
except ImportError:
print "Missing %s" % os.path.join(PROJECT_ROOT, "local_settings.py")
if DEBUG:
for p in [PROJECT_ROOT, MEDIA_ROOT, THEME_DIR, ADMIN_MEDIA_ROOT] + list(TEMPLATE_DIRS):
p = os.path.normpath(p)
if not os.path.exists(p):
print "Missing path: %s" % p
答案 3 :(得分:3)
我们使用顶级urls.py
。
答案 4 :(得分:3)
我测试了所有三个__init__.py Settings.py和urls.py方法,这就是我找到的。
当代码从__init__.py或Settings.py运行时,启动功能在Web服务器启动时运行两次;当从urls.py运行启动函数时,代码运行一次,但它仅在第一次向我们的服务器发出请求时运行,导致第一个用户可能需要等待很长时间才能访问你的网站。
标准做法是在将大型Web应用程序重新联机时调用“预热”页面,因此我没有看到从urls.py中明确标识的位置调用启动函数应该是个问题。
答案 5 :(得分:0)
你可以把它放在其他人提到的settings.py中,但在设置中使用代码并不理想。还可以选择为django.db.models.signals.class_prepared添加处理程序,该处理程序在准备好特定模型类之后执行所需的启动检查。
答案 6 :(得分:0)
这里的大多数答案都非常古老,所以我认为这就是为什么没有提到Django's checks framework的原因。
自从至少v2(在撰写本文时,django == 3.1)开始,它就一直是django的一部分。
这可能是您需要的大多数支票的正确位置。
我仍会考虑使用settings
,如其他答案所述,以检查需要settings
内容的地方,但还需要在准备应用程序之前运行这些内容。