Caching is not invalidated

[lekhnath]

Caching is not invalidated

[agateblue]

Hi @agateblue

I haven't setup any particular "CACHES" settings in Django. The usual Django cache is being used for now.

This is the source of your issue then. The default cache is using local process memory (https://docs.djangoproject.com/en/5.0/ref/settings/#caches).

As each process get a distinct and indépendant cache, your management command does not update the cache of your server process.

You need to switch to another cache backend that is shared between processes (such as redis, memcached or file, though performances could be worse than no caching with this last one) or disable caching for dynamic preferences entirely.

[lekhnath]

I sincerely appreciate your advice, @agateblue. Much obliged. I am planning to use the redis cache. I hope it resolves my problem. I'm going to close now. In case this problem persists after the use of alternative caching mechanisms, I will open another issue.

[agateblue]

You're welcome, I'm glad it helped :)

[agateblue]

In middleware.py, can you try moving global_preferences = global_preferences_registry.manager() inside the middleware function, like this:

def maintenance_middleware(get_response):
    def middleware(request):
        # We instantiate a manager for our global preferences
        global_preferences = global_preferences_registry.manager()
        if global_preferences['maintenance_mode'] == True:
            return HttpResponse(
                'Maintenance', status=status.HTTP_503_SERVICE_UNAVAILABLE
            )

        response = get_response(request)

        return response

    return middleware

I suspect some caching is occuring there, and because the manager is instanciated at the top level of the module, the value is cached on first access and never updated.

It would also be nicer to update the cache when the number changes

I'm not sure what you mean by that, could you clarify?

[lekhnath]

Eventually, the changed value was read. It took a while—maybe because it was after cache ttl or because I wasn't patient enough—but it was read. I tried moving the call to the manager inside a middleware method, like you suggested, but it didn't affect anything. It shows up after a while, even if I change it straight from the database.

PS: Sorry for the typo there It would also be nicer to update the cache when the number changes. I meant when the value changes in database.

[agateblue]

We do invalidate the cache in case on an update. This happens through a post save signal here:

django-dynamic-preferences/dynamic_preferences/models.py

Line 132 in 6712ace

manager.to_cache(instance)

Which triggers

django-dynamic-preferences/dynamic_preferences/managers.py

Line 107 in 6712ace

def to_cache(self, *prefs):

Can you share your settings.CACHES configuration? I'm wondering what type of cache you are using.

[lekhnath]

Hi @agateblue

I haven't setup any particular "CACHES" settings in Django. The usual Django cache is being used for now.

[lekhnath]

This is my current settings for dyanamic_preferences :

# available settings with their default values
DYNAMIC_PREFERENCES = {

    # a python attribute that will be added to model instances with preferences
    # override this if the default collide with one of your models attributes/fields
    'MANAGER_ATTRIBUTE': 'preferences',

    # The python module in which registered preferences will be searched within each app
    'REGISTRY_MODULE': 'preferences_registry',

    # Allow quick editing of preferences directly in admin list view
    # WARNING: enabling this feature can cause data corruption if multiple users
    # use the same list view at the same time, see https://code.djangoproject.com/ticket/11313
    'ADMIN_ENABLE_CHANGELIST_FORM': False,

    # Customize how you can access preferences from managers. The default is to
    # separate sections and keys with two underscores. This is probably not a settings you'll
    # want to change, but it's here just in case
    'SECTION_KEY_SEPARATOR': '__',

    # Use this to disable auto registration of the GlobalPreferenceModel.
    # This can be useful to register your own model in the global_preferences_registry.
    'ENABLE_GLOBAL_MODEL_AUTO_REGISTRATION': True,

    # Use this to disable caching of preference. This can be useful to debug things
    'ENABLE_CACHE': True,

    # Use this to select which chache should be used to cache preferences. Defaults to default.
    'CACHE_NAME': 'default',

    # Use this to disable checking preferences names. This can be useful to debug things
    'VALIDATE_NAMES': True,
}