[英]Overriding settings in Django when used by the models
We are using Django for Speedy Net and Speedy Match (currently Django 2.1).我们将 Django 用于Speedy Net 和 Speedy Match (当前为 Django 2.1)。 Some of our settings are used by the models.
我们的一些设置被模型使用。 For example:
例如:
class USER_SETTINGS(object):
MIN_USERNAME_LENGTH = 6
MAX_USERNAME_LENGTH = 40
MIN_SLUG_LENGTH = 6
MAX_SLUG_LENGTH = 200
# Users can register from age 0 to 180, but can't be kept on the site after age 250.
MIN_AGE_ALLOWED_IN_MODEL = 0 # In years.
MAX_AGE_ALLOWED_IN_MODEL = 250 # In years.
MIN_AGE_ALLOWED_IN_FORMS = 0 # In years.
MAX_AGE_ALLOWED_IN_FORMS = 180 # In years.
MIN_PASSWORD_LENGTH = 8
MAX_PASSWORD_LENGTH = 120
MAX_NUMBER_OF_FRIENDS_ALLOWED = 800
PASSWORD_VALIDATORS = [
{
'NAME': 'speedy.core.accounts.validators.PasswordMinLengthValidator',
},
{
'NAME': 'speedy.core.accounts.validators.PasswordMaxLengthValidator',
},
]
(which is defined in https://github.com/speedy-net/speedy-net/blob/staging/speedy/net/settings/global_settings.py ). (在https://github.com/speedy-net/speedy-net/blob/staging/speedy/net/settings/global_settings.py中定义)。 And then in the models I use:
然后在我使用的模型中:
from django.conf import settings as django_settings
class User(ValidateUserPasswordMixin, PermissionsMixin, Entity, AbstractBaseUser):
settings = django_settings.USER_SETTINGS
(and then use attributes of settings
, such as settings.MIN_SLUG_LENGTH
, in the class). (然后在类中使用
settings
的属性,例如settings.MIN_SLUG_LENGTH
)。
The problem is, when I try to override such settings in tests (you can see my question & answer on Can I define classes in Django settings, and how can I override such settings in tests? ), User.settings
remains the same and is not overridden by the settings I tried to override.问题是,当我尝试在测试中覆盖此类设置时(您可以在我可以在 Django 设置中定义类,以及如何在测试中覆盖此类设置?上查看我的问题和答案),
User.settings
保持不变并且是没有被我试图覆盖的设置覆盖。 This is a problem since in the model I passed settings.MIN_SLUG_LENGTH
for example to validators, which are also passed other values by other models.这是一个问题,因为在模型中我将
settings.MIN_SLUG_LENGTH
传递给了验证器,其他模型也传递了其他值。 Is it possible to define the models and settings in such a way which the correct settings will be used both in production and in tests, including when I want to override them?是否可以以在生产和测试中都使用正确设置的方式定义模型和设置,包括当我想覆盖它们时?
I'm aware of this quote from https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings :我从https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings知道这句话:
Warning
警告
The settings file contains some settings that are only consulted during initialization of Django internals.
设置文件包含一些仅在 Django 内部初始化期间参考的设置。 If you change them with override_settings, the setting is changed if you access it via the django.conf.settings module, however, Django's internals access it differently.
如果您使用 override_settings 更改它们,如果您通过 django.conf.settings 模块访问它,则设置会更改,但是,Django 的内部访问它的方式不同。 Effectively, using override_settings() or modify_settings() with these settings is probably not going to do what you expect it to do.
实际上,使用带有这些设置的 override_settings() 或 modify_settings() 可能不会达到您期望的效果。
We do not recommend altering the DATABASES setting.
我们不建议更改 DATABASES 设置。 Altering the CACHES setting is possible, but a bit tricky if you are using internals that make using of caching, like django.contrib.sessions.
改变 CACHES 设置是可能的,但如果你使用的是使用缓存的内部机制,比如 django.contrib.sessions,那就有点棘手了。 For example, you will have to reinitialize the session backend in a test that uses cached sessions and overrides CACHES.
例如,您必须在使用缓存会话并覆盖 CACHES 的测试中重新初始化会话后端。
Finally, avoid aliasing your settings as module-level constants as override_settings() won't work on such values since they are only evaluated the first time the module is imported.
最后,避免将您的设置别名为模块级常量,因为 override_settings() 不会对此类值起作用,因为它们仅在第一次导入模块时进行评估。
Which I understand are relevant in this case, but how do I define the settings in such a way that I can override them?我理解在这种情况下是相关的,但是我如何以可以覆盖它们的方式定义设置?
Function _1___set_up
in speedy/core/base/test/models.py is a workaround to make the tests work, but this is a hack and I don't think it's a good solution for the long term. speedy/core/base/test/models.py 中的函数
_1___set_up
是使测试工作的解决方法,但这是一种 hack,我认为从长远来看这不是一个好的解决方案。
The problem, as you quoted:正如您所引用的那样,问题是:
avoid aliasing your settings as module-level constants as
override_settings()
won't work on such values since they are only evaluated the first time the module is imported.避免将您的设置别名为模块级常量,因为
override_settings()
不会对此类值起作用,因为它们仅在第一次导入模块时进行评估。
There are 3 ways around this, where Way 1 > Way 3 > Way 2 .有 3 种方法,其中Way 1 > Way 3 > Way 2 。
classproperty
classproperty
Recommended;推荐的; arguably the correct way.
可以说是正确的方法。
from django.utils.decorators import classproperty
class User(PermissionsMixin, Entity, AbstractBaseUser):
# settings = django_settings.USER_SETTINGS
@classproperty
def settings(cls):
return django_settings.USER_SETTINGS
Caveat : Class attributes that depend on the settings
class attribute won't work.警告:依赖于
settings
类属性的类属性将不起作用。
Although Way 2 allows the following code to still be valid, these are evaluated at class definition (import) time and cannot reasonably change based on override_settings()
, unless they are classproperty
too.尽管方法 2允许以下代码仍然有效,但这些代码是在类定义(导入)时评估的,并且不能根据
override_settings()
进行合理更改,除非它们也是classproperty
。
AGE_VALID_VALUES_IN_MODEL = range(settings.MIN_AGE_ALLOWED_IN_MODEL, settings.MAX_AGE_ALLOWED_IN_MODEL)
AGE_VALID_VALUES_IN_FORMS = range(settings.MIN_AGE_ALLOWED_IN_FORMS, settings.MAX_AGE_ALLOWED_IN_FORMS)
django_settings
django_settings
Not recommended;不建议; impacts the runtime evaluation of USER_SETTINGS also in production, not only in tests (@hynekcer) .
影响 USER_SETTINGS 的运行时评估也在生产中,而不仅仅是在测试中(@hynekcer) 。
overridable_settings
:overridable_settings
:def overridable_settings(settings_class):
old__getattribute__ = settings_class.__getattribute__
settings_name = settings_class.__name__
def patched__getattribute__(_self, item):
from django.conf import settings as django_settings
settings = getattr(django_settings, settings_name)
return old__getattribute__(settings, item)
settings_class.__getattribute__ = patched__getattribute__
return settings_class()
django_settings.USER_SETTINGS
is now an instance of the settings class. django_settings.USER_SETTINGS
现在是设置类的一个实例。 Instead of get_django_settings_class_with_override_settings
, define override_settings
:get_django_settings_class_with_override_settings
,定义override_settings
:import copy
def override_settings(settings, **overrides):
copied_settings = copy.deepcopy(settings)
for setting, value in overrides.items():
setattr(copied_settings, setting, value)
assert copied_settings != settings
return copied_settings
Usage:用法:
@overridable_settings
class USER_SETTINGS(object):
from speedy.core.base.test import utils
# @override_settings(USER_SETTINGS=get_django_settings_class_with_override_settings(django_settings_class=django_settings.USER_SETTINGS, MIN_SLUG_LENGTH=tests_settings.OVERRIDE_USER_SETTINGS.MIN_SLUG_LENGTH))
@override_settings(USER_SETTINGS=utils.override_settings(django_settings.USER_SETTINGS, MIN_SLUG_LENGTH=tests_settings.OVERRIDE_USER_SETTINGS.MIN_SLUG_LENGTH))
def test_slug_min_length_fail_username_min_length_ok(self):
setting_changed
to update aliassetting_changed
的接收器以更新别名 From https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings :来自https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings :
When overriding settings, make sure to handle the cases in which your app's code uses a cache or similar feature that retains state even if the setting is changed.
覆盖设置时,请确保处理您的应用程序代码使用缓存或类似功能的情况,即使设置更改也能保留状态。 Django provides the
django.test.signals.setting_changed
signal that lets you register callbacks to clean up and otherwise reset state when settings are changed.Django 提供了
django.test.signals.setting_changed
信号,允许您注册回调以在设置更改时清理或重置状态。Django itself uses this signal to reset various data.
Django 本身使用这个信号来重置各种数据。
from django.core.signals import setting_changed
from django.dispatch.dispatcher import receiver
def register_django_setting_alias(setting_alias, django_setting):
def decorator(cls):
@receiver(setting_changed, weak=False)
def update_setting_alias(setting, value, **_):
if setting == django_setting:
setattr(cls, setting_alias, value)
return cls
return decorator
Usage:用法:
@register_django_setting_alias('settings', 'USER_SETTINGS')
class User(PermissionsMixin, Entity, AbstractBaseUser):
settings = django_settings.USER_SETTINGS
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.