Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#12737 closed Uncategorized (wontfix)

Thread local settings

Reported by: German M. Bravo Owned by: nobody
Component: Uncategorized Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

#thread_local_settings.diff (2.8 KB) - added by German M. Bravo 5 years ago.
Thread local settings

Download all attachments as: .zip

Change History (6)

comment:1 Changed 7 years ago by Alex Gaynor

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedDesign decision needed

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

comment:2 Changed 6 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

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

Changed 5 years ago by German M. Bravo

Attachment: #thread_local_settings.diff added

Thread local settings

comment:3 Changed 5 years ago by German M. Bravo

Easy pickings: unset
Resolution: wontfix
Severity: Normal
Status: closedreopened
Type: Uncategorized
UI/UX: unset

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.

comment:4 Changed 5 years ago by anonymous

Resolution: wontfix
Status: reopenedclosed

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.

comment:5 Changed 5 years ago by Alex Gaynor

that was me.

Note: See TracTickets for help on using tickets.
Back to Top