在运行时更改Django设置 [英] Changing Django settings at runtime

问题描述

我想将一些（应用程序特定的）设置公开到管理界面，所以用户可以舒适地改变它们，也不必重新启动Django。

我应该怎么做？

我在 http://djangopackages.com/grids/g/live-setting/ （btw django-constance是最有吸引力的），但是真正的所有这些应用程序正在做的是将值存储在数据库中，提供一个Web界面来改变它们，并进行缓存。 Django中没有内置的前两个功能？

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

我不能这样做吗？

1. 为我的设置创建一个模型（这给了我各种类型和验证）


2. 实例化一个这样的对象来保存我的设置（这允许用户在管理界面中进行编辑） - 我可以将默认值转换为与其他模型类似的设备。


3. 包含settings.py，使其成为数据库查询我的设置 - http：// www .loose-bits.com / 2011/04 / extend-django-settings-with-derived.html

从我目前的天真观点只有d我看到的rawbacks将是：

1. 添加或更改可用设置需要模式迁移（南）。 - 我可以和他一起生活。


2. 我有一个可能有多个实例的模型，但实际上只需要一个单例。 - 这实际上可能是一个有用的功能。


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


4. 在另一个项目中执行相同的操作需要再次进行类似的工作。 - 我认为settings.py中的单一字典常数，用于查找的模型名称和字段名称都会有所不同。

这不会是两个世界中最好的 - 运行时管理员（具有所有的优点），数据库后端，缓存，以及我的任何设置.USED_TO_BE_IN_SETTINGS_DOT_PY将需要更改。我错过了什么吗？

解决方案

AFAIK，Django设置应该是不可变的。这有多个原因，最明显的是Django不知道服务器的执行模型（prefork / multi-threaded）。

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

所以基本上你有两个解决方案： p>

• 您可以使用任何较低级别的数据库访问机制来加载数据库中的设置;或


• ，您可以在其他型号中定义您的设置，并在需要时直接提取。

第一个是令人难以置信的黑客，我不建议。第二个是更直接和更干净，但要求您改变常规习惯（从django.conf导入设置）。

第二种方法可能是您链接到的第三方应用程序实现的。

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.

How should I go about this?

I checked out the applications on http://djangopackages.com/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?

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.

Couldn't I just do this?

1. Create a model for my settings (this gives me the various types and validation)
2. Instantiate one such object to hold my settings (this allows the users to edit them in the admin interface) - I could dump defaults as fixtures like for other models
3. Wrap settings.py so it makes a database query for my settings - http://www.loose-bits.com/2011/04/extending-django-settings-with-derived.html

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

1. Adding or changing the available settings requires a schema migration (south). - I can live with that.
2. I have a model with possibly multiple instances but really only need a singleton. - That could actually be a useful feature at some point.
3. Performance/Caching: Looking at http://code.djangoproject.com/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.
4. 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.

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, 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).

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:

• you can bootstrap the settings from the database by using any lower-level database access mechanism to load them; or
• you can just define your settings in some other model and fetch them directly when you need them.

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).

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

这篇关于在运行时更改Django设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！