On Jan 31, 1:49 am, Xavier Ordoquy <xordo...@linovia.com> wrote: > The thread is pretty long because there are also 2 threads in one: > - one for simply changing the site_id per request > - one for changing the all setting per request
Exactly! For the record, as far as I'm concerned #15089 is limited in scope to the first issue: making contrib.sites provide API for getting a Site object that projects can configure such that the returned Site object is based on the request, without having to resort to threadlocals. This may not satisfy everyone's definition of "true multitenancy," but it covers a lot more use cases than contrib.sites does now. For those whose definition of "true multitenancy" requires being able to modify arbitrary settings at runtime per-request, I see only two realistic (thread-safe) options: 1) Using threadlocals, as discussed above. 2) Fixing Django's settings to be an instance of some kind of configured "app" object (a la Flask, except we can't call it an app because we already use that name for something different) rather than a process global. I don't know that anyone disagrees this would be better in principle, but I haven't seen any proposals yet for how to do it in a backwards-compatible way (though I'm not sure that means it's impossible). If it can't be done backwards-compatibly, that puts it in the Django 2.0 timeframe (i.e. in the foggy mists of some unknown future time). Carl -- 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.
