Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#12737 closed Uncategorized (wontfix)

Thread local settings

Reported by: Kronuz 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 Kronuz 4 years ago.
Thread local settings

Download all attachments as: .zip

Change History (6)

comment:1 Changed 5 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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

comment:2 Changed 5 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

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 4 years ago by Kronuz

Thread local settings

comment:3 Changed 4 years ago by Kronuz

  • Easy pickings unset
  • Resolution wontfix deleted
  • Severity set to Normal
  • Status changed from closed to reopened
  • Type set to 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 4 years ago by anonymous

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 4 years ago by Alex

that was me.

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