I believe this ticket: http://code.djangoproject.com/ticket/14628
which was created during this chat session http://www.revsys.com/officehours/2010/nov/05/#question5 is also relevant to the issue at hand. An interesting bit of that chat is: jacobkmnicoechaniz: one hint is that although the documentation says that you shouldn't modify settings at runtime, in fact many of them *can* be changed at runtime without problems. Unfortunately there's a bit of a trial-and-error in figuring out which.Ticket #14628 describes the situation. The proposals in Ticket #15089 (and the related thread) approach the multi-tenancy problem by providing the means to determine the current site dynamically, but this, IMHO, does not fully solve the issue. In our case (it's described in the chat-log) we have 1500 sites which would benefit from having separate settings files as there are configuration details which change from one to the other. These are not only core and contrib but also external apps, like django-filebrowser for example, for which we have different upload limits per client; we use some 10 external apps or more. What we have been working on makes use of the threadlocals approach and a proxy object for settings values. This way, whenever some code is trying to get the value for a setting, the actual value is determined from the settings corresponding to the site being requested. All of this has worked very well to a certain extent, but we have had a very hard time figuring out which settings can actually be overridden at runtime and which can't. I believe that to achieve true multi-tenancy it should be made very clear when a setting is meant to stay unchanged and when it's OK to change it at runtime. The above mentioned ticket proposes this distinction for django settings but a complete resolution should also involve a strategy to allow third party app developers to easily make this same distinction in their own code. Eventually, apps could state if they are multi-tenancy compatible (all settings can be changed at runtime). Maybe an easy way to accomplish this separation would be to have dynamic and static settings live in different files, which would make it self explanatory. It would be up to the developer of each app to understand which of his settings can actually be changed at runtime ad which can't. What we have implemented ATM for our specific problem is a "man in the middle" (using twisted) which spawns server processes based on the requested site and only keeps alive a number of them and discards those that have been idle for a while. This is only useful in a situation like ours where most of the sites get very little hits per day, but it's been working just fine so far. The code (needs some love and generalization) is available at: http://bitbucket.org/san/luisito On Sun, Jan 30, 2011 at 3:39 PM, Daniel Moisset <[email protected]>wrote: > On Sun, Jan 30, 2011 at 2:20 AM, Russell Keith-Magee > <[email protected]> wrote: > > > > Every single problem associated with using global variables exists > > with threadlocals -- and then a few more. They *can* be used > > successfully. However, in almost every case, they can also be avoided > > entirely with a good dose of rigorous engineering. > > > > I *strongly* advise against the use of this technique. > > > > I understand (and completely support) your objection, specially when > someone says «one could save even the request object to thread > "global" and it would be accessible anywhere.» (which would make code > using requests, i.e. a lot of it harder to reuse and to test) > > But the core problem being solved here, about moving SITE_ID to a > threadlocal, doesn't look like bad engineering to me. In fact is > moving something that is already global (everything in settings.py is) > to alocation which is *less* global (thread-wise instead of > process-wise). So this is an increase in locality, if I got it > right... > > In which way is this worse than the current state of a global > variable? (and in general, do you have some reference to explain > «Every single problem associated with using global variables exists > with threadlocals -- and then a few more»? I tend to think that a > thread local is generally better than a global, even if it tends to be > worse that good API design/argument passing) > > Regards, > D. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
