模型使用时覆盖 Django 中的设置

Question

我们将 Django 用于Speedy Net and Speedy Match（当前为 Django 2.1）。我们的一些设置被模型使用。例如：

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',
        },
    ]

（在https://github.com/speedy-net/speedy-net/blob/staging/speedy/net/settings/global_settings.py 中定义）。然后在我使用的模型中：

from django.conf import settings as django_settings

class User(ValidateUserPasswordMixin, PermissionsMixin, Entity, AbstractBaseUser):
    settings = django_settings.USER_SETTINGS

（然后在类中使用settings的属性，如settings.MIN_SLUG_LENGTH）。

问题是，当我尝试在测试中覆盖此类设置时（您可以在 Can I define classes in Django settings, and how can I override such settings in tests? 上查看我的问题和答案），User.settings 保持不变，并且不会被我尝试覆盖的设置所覆盖。这是一个问题，因为在模型中我将settings.MIN_SLUG_LENGTH 传递给了验证器，其他模型也传递了其他值。是否可以定义模型和设置，以便在生产和测试中都使用正确的设置，包括当我想要覆盖它们时？

我知道https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings 的这句话：

警告

设置文件包含一些仅供参考的设置 在 Django 内部初始化期间。如果你用 override_settings，如果您通过 django.conf.settings 模块，然而，Django 的内部访问它 不同。有效地，使用 override_settings() 或 具有这些设置的 modify_settings() 可能不会做什么 你期望它做。

我们不建议更改 DATABASES 设置。改变 CACHES 设置是可能的，但如果您使用的是有点棘手 使用缓存的内部结构，例如 django.contrib.sessions。 例如，您将不得不重新初始化会话后端 使用缓存会话并覆盖 CACHES 的测试。

最后，避免将您的设置别名为模块级常量 override_settings() 不会对这些值起作用，因为它们只是 第一次导入模块时进行评估。

我理解在这种情况下是相关的，但我如何定义设置以便我可以覆盖它们？

speedy/core/base/test/models.py 中的函数 _1___set_up 是一种使测试正常工作的解决方法，但这是一种 hack，我认为从长远来看这不是一个好的解决方案。

Answer 1

问题，正如你所引用的：

避免将您的设置别名为模块级常量，因为 override_settings() 不会对此类值起作用，因为它们仅在第一次导入模块时进行评估。

有 3 种方法可以解决这个问题，其中 Way 1 > Way 3 > Way 2。

方式1：不要用class属性别名，而是classproperty

推荐；可以说是正确的方法。

• 专业版：最具表现力，更易于调试。
• 缺点：模型中有更多代码。

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

警告：依赖于settings 类属性的类属性将不起作用。

虽然 方式 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)

方式 2：补丁设置类，因此实例读取 django_settings

不推荐； 影响 USER_SETTINGS 的运行时评估也在生产中，而不仅仅是在测试中 (@hynekcer)。

• 专业版：模型中没有代码更改。
• 缺点：表达能力最差，更难调试。
  
  

1. 定义一个函数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()

1. django_settings.USER_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

用法：

@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):

方式3：创建信号setting_changed的接收者更新别名

• 专业版：对模型的代码更改最少。
• 缺点：在 Caveat 中的依赖属性方面，表现力不如 Way 1。

来自https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings：

覆盖设置时，请确保处理应用代码使用缓存或类似功能的情况，即使设置更改也会保留状态。 Django 提供django.test.signals.setting_changed 信号，允许您注册回调以在设置更改时清理或重置状态。

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

用法：

@register_django_setting_alias('settings', 'USER_SETTINGS')
class User(PermissionsMixin, Entity, AbstractBaseUser):
    settings = django_settings.USER_SETTINGS