Thread local settings

[German M. Bravo]

Many times I'm in the need of modify (perhaps wrongly) the settings in django.conf.settings... assuming the setting being modified is set up on every request (such as it could be the LANGUAGE_CODE, from the session, the URL or a cookie... or the SITE_ID fro the URL, for dynamic hosting) in some middleware perhaps... then it shouldn't be as "bad" to do so... or could it? (or so I thought) when I started using django, something that was not obvious for me was that settings where shared among threads too... and after testing everything locally it worked fine, but when I tried my project in a system with Apache and multiprocess/multithreaded environment it had weird things happening some times...

After some time I realized settings where being modified by different threads during the same request, making my dynamic sites behave erratically and my languages change from here to there in mysterious ways.

The attached patch allows settings to be local to the threads, making it safe to modify of certain settings in a per request basis.

[Alex Gaynor]

Marking as DND, but I think this should be marked wontfix. This isn't what settings are for.

[Malcolm Tredinnick]

Settings aren't designed to be changed locally like this and we somewhat intentionally cache things that are settings derived (so they would have to be triggered on settings changes, etc). Using threadlocals isn't appropriate here. Anything that needs per-request changes shouldn't be settings controlled (e.g. language settings can be activated in other ways).

[German M. Bravo]

Thread local settings

[German M. Bravo]

I'm taking the liberty to reopen this ticket again, so we can discuss the issue a bit further.

As an extra point for this, having settings be configurable like this, in the way this patch allows, would allow us to call settings.clear() just before (or after) the request begins (or ends), effectively cleaning up all settings the user might have messed with during the request. I'm not entirely sure of all the benefits of this, I think there are some, and the way settings objects are now, this fits perfectly... otherwise, if settings are not to be writeable, we could as well rise an error if the user tries to write to the settings object.

[anonymous]

The appropriate course of action if you disagree with a ticket that was wontfixed by a core developer is to bring it up on the mailing list, not to reopen the ticket.

[Alex Gaynor]

^{that was me.}