在运行时更改 Django 设置

本文介绍了在运行时更改 Django 设置的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我想向管理界面公开一些(特定于应用程序的)设置，以便用户可以轻松地更改它们，而不必重新启动 Django.

I'd like to expose some (app-specific) settings to the admin interface, so users can change them comfortably and also not have to restart Django.

我应该怎么做?

我查看了 djangopackages/grids/g/live 上的应用程序-setting/(顺便说一句，django-constance 是最吸引人的)但实际上所有这些应用程序所做的是将值存储在数据库中，提供一个 Web 界面来更改它们，并进行缓存.前两个功能不是已经内置到 Django 中了吗?

I checked out the applications on djangopackages/grids/g/live-setting/ (btw django-constance was the most appealing) but really what all these apps are doing is storing values in a database, providing a web interface to change them, and caching. Aren't the first two features already built into Django?

我看到的最大缺点是没有一个应用程序可以直接替换这些设置的旧位置 (settings.py)，并且需要我迁移到它们的符号，并且经常添加另一个上下文处理器来访问它们在模板中.

The biggest drawbacks I see are that none of the apps are drop-in replacements for the old location of these settings (settings.py), and require me to migrate to their notation, and often add another context processor to access them in templates.

我不能这样做吗?

为我的设置创建一个模型(这为我提供了各种类型和验证)

实例化一个这样的对象来保存我的设置(这允许用户在管理界面中编辑它们) - 我可以像其他模型一样将默认值转储为装置

包装 settings.py 以便对我的设置进行数据库查询 - www.loose-bits/2011/04/extending-django-settings-with-derived.html

从我目前的天真观点来看，我看到的唯一缺点是:

From my current, naive point of view the only drawbacks I see would be:

添加或更改可用设置需要架构迁移(向南).- 我可以忍受.

我有一个可能有多个实例的模型，但实际上只需要一个单例.- 在某些时候，这实际上可能是一个有用的功能.

性能/缓存:查看 code.djangoproject/svn/django/trunk/django/conf/ 我必须在设置包装器和/或模型中加一点聪明才智，以便模型更改清除或更新缓存值.- 似乎不是火箭科学.

在另一个项目中执行相同的操作需要再次进行类似的工作.- 我认为 settings.py 中的单个字典常量，包含用于查找的模型名称和字段名称是唯一不同的.

Adding or changing the available settings requires a schema migration (south). - I can live with that.

I have a model with possibly multiple instances but really only need a singleton. - That could actually be a useful feature at some point.

Performance/Caching: Looking at code.djangoproject/svn/django/trunk/django/conf/ I'd have to put a little bit of cleverness into the settings wrapper and/or model, so that model changes clear or update cached values. - doesn't seem to be rocket science.

Doing the same in another project would require a similar effort again. - I think a single dictionary constant in settings.py, holding model name(s) and field names for the lookups is all that would differ.

这难道不是两全其美 - 运行时管理员(及其所有特权)、数据库后端、缓存和我的任何设置.USED_TO_BE_IN_SETTINGS_DOT_PY 不需要任何更改.我错过了什么吗?

Wouldn't this be the best of both worlds - runtime admin (with all its perks), database backend, caching, and none of my settings.USED_TO_BE_IN_SETTINGS_DOT_PY would need any changing. Am I missing something?

推荐答案

AFAIK，Django 设置应该是不可变的.造成这种情况的原因有多种，最明显的是 Django 不知道服务器的执行模型(prefork/multi-threaded).

AFAIK, the Django settings are supposed to be immutable. There are multiple reasons for this, the most obvious being that Django is not aware of the server's execution model (prefork / multi-threaded).

此外，您不能从 Django 模型中加载设置本身，因为需要先加载设置，然后才能在 ORM 中使用任何内容.

Also, you can't load the settings themselves from a Django model because the settings need to be loaded before you can use anything in the ORM.

所以，基本上，您有两种解决方案:

So, basically, you have two solutions:

• 您可以通过使用任何较低级别的数据库访问机制来加载数据库中的设置；或
• 您可以在其他模型中定义您的设置，并在您需要时直接获取它们.

第一个是令人难以置信的黑客，我不建议这样做.第二个更直接更干净，但需要你改变你平时的习惯(from django.conf import settings).

The first is an incredible hack and I don't suggest it. The second is much more direct and cleaner, but requires you to change your usual habits (from django.conf import settings).

第二种方法可能是您链接到的第 3 方应用所实施的方法.

The second approach is probably what's implemented by the 3rd-party apps you linked to.