This post is getting pretty long. But I had a simple Django fix that would make it work a lot easier for me, and might help others. (I say this because of how I implemented it, I am working with about 60 different sites and it is a pretty simple arrangement)
Imagine you were able to set a site_id per request rather than relying on the settings SITE_ID. Django would then checked for a request's site_id *first *and then *second *check the settings one. It is really simple, but it would fix a lot of my problems and avoid having to switch around the settings SITE_ID per request. Setting the requests site_id with middleware is straightforward enough and further customizations to the request. Changing the urls for example. This approach would avoid: - Threading issus, and global variables - Adding new functions to work with (Saves time and pain, documentation, testing, releases so forth) - Doesn't break things that are tied into the Sites Framework(site-maps, comments, etc...) It also feels a little more DRY to me. Let me know if I have assumed something I shouldn't have. I don't know much about how the current implementation and use of SITE_ID in the backend. Cheers, James Hancock On Mon, Jan 31, 2011 at 6:09 AM, lwcy...@gmail.com <lwcy...@gmail.com>wrote: > 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 > <dmois...@machinalis.com>wrote: > >> On Sun, Jan 30, 2011 at 2:20 AM, Russell Keith-Magee >> <russ...@keith-magee.com> 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 django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> >> . >> 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 django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
