Home/ Questions/Q 6357565
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T23:11:26+00:00

I want create project wide accessible storage for project/application settings. What i want to

  • 0

I want create project wide accessible storage for project/application settings.

What i want to achieve: – Each app has it’s own app specific settings stored in db – When you spawn django wsgi process each settings are stored in memory storage and are available project wide – Whenever you change any setting value in db there is a call to regenerate storage from db

So it works very close to cache but I can’t use cache mechanism because it’s serializing data. I can also use memcache for that purpose but i want to develop generic solution (not always you have access to memcache).

If anyone have any ideas to solve my problem i would be really gratefully for sharing.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Before giving any specific advice to you, you need to be aware of the limitations of these systems.

    ISSUES

    • Architectural Differences between Django and PHP/other popular language.

      PHP re-reads and re-evaluates the entire code tree every time a page is accessed. This allows PHP to re-read settings from DB/cache/whatever on every request.

    • Initialisation

      Many django apps initialise their own internal cache of settings and parameters and perform validation on these parameters at module import time (server start) rather than on every request. This means you would need a server restart anyway when modifying any settings for non db-settings enabled apps, so why not just change settings.py and restart server?

    • Multi-site/Multi-instance and in-memory settings

      In Memory changes are strictly discouraged by Django docs because they will only affect a single server instance. In the case of multiple sites (contrib.sites), only a single site will recieve updates to shared settings. In the case of instanced servers (ep.io/gondor) any changes will only be made to a local instance, not every instance running for your site. Tread carefully

    PERFORMANCE

    • In Memory Changes

      Changing settings values while the server is running is strictly discouraged by django docs for the reasons outlined above. However there is no performance hit with this option. USE ONLY WITHIN THE CONFINES OF SPECIFIC APPS MADE BY YOU AND SINGLE SERVER/INSTANCE.

    • Cache (redis-cache/memcached)

      This is the intermediate speed option. Reasonably fast lookup of settings which can be deserialised into complex python structures easily – great for dict-configs. IMPORTANT is that values are shared among Sites/Instances safely and are updated atomically.

    • DB (SLOOOOW)

      Grabbing one setting at a time from DB will be very very slow unless you hack in connection pooling. grabbing all settings at once is faster but increases db transfer on every single request. Settings synched between Sites/Instances safely. Use only for 1 or 2 settings and it would be reasonable to use.

    CONCLUSION

    Storing configuration values in database/cache/mem can be done, but you have to be aware of the caveats, and the potential performance hit. Creating a generic replacement for settings.py will not work, however creating a support app that stores settings for other apps could be a viable solution, as long as the other apps accept that settings must be reloaded every request.

    • 0