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

Question

我们将 Django 用于Speedy Net 和 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）。

问题是，当我尝试在测试中覆盖这样的设置（你可以看到我的问题及答案我可以在Django的设置定义类，我怎么能在测试中覆盖这样的设置？），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 设置。更改缓存设置是可能的，但如果您使用使用缓存的内部组件，例如 django.contrib.sessions，则有点棘手。例如，您必须在使用缓存会话并覆盖 CACHES 的测试中重新初始化会话后端。

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

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

功能_1___set_up在快速/核心/基/测试/ models.py是一种变通方法，以使测试工作，但是这是一个黑客，我不认为这是一个长期的良好的解决方案。

Answer 1

问题，正如你所引用的：

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

有 3 种方法可以解决此问题，其中方式 1 >方式 3 >方式 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

不建议; 不仅在测试 (@hynekcer) 中，还会影响生产中 USER_SETTINGS 的运行时评估。

• 优点：模型中没有代码更改。
• 缺点：表现力最差，更难调试。
  
  

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

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

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

• 优点：对模型的代码更改最少。
• 缺点：就Caveat 中的依赖属性而言，不如方式 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