#15089: contrib.sites and multitenancy
-------------------------------------+-------------------------------------
     Reporter:  legutierr            |                    Owner:  apollo13
         Type:  New feature          |                   Status:  new
    Component:  contrib.sites        |                  Version:
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Design
    Has patch:  1                    |  decision needed
  Needs tests:  0                    |      Needs documentation:  0
Easy pickings:  0                    |  Patch needs improvement:  1
                                     |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by anonymous):

 I like the latest patch as it's lightweight and somehow mitigates the
 issue, it'll reduce to the minimum the number of hacks required to achieve
 multitenancy.

 It's worth noting that there are a few places in django that use
 SiteManager.get_current() instead of get_current_site(). A quick scan gave
 me sitemaps, comment feeds and comment moderation. These are usually from
 functions that don't have access to the request. I'd say this patch should
 include some refactoring to completely remove get_current() usage. It
 should probably be documented that any use of get_current() in third-party
 apps will break multitenancy, instead of recommending get_current() as
 it's currently the case, it should be strongly advised against.

 Proper multitenancy is still not achieved, even with this patch, because
 it doesn't address things like MEDIA_ROOT, MEDIA_URL,
 EMAIL_SUBJECT_PREFIX, DEFAULT_FROM_EMAIL that are needed for most
 multitenant usages.

 For completeness I'll also mention TIME_ZONE, LANGUAGE_CODE and
 ROOT_URLCONF that are important elements of multitenancy as well, even
 though it's already possible to affect their value on a per request basis
 without resorting to terrible hacks.

 To solve this issue some people resort to wrapping settings and storing
 their values in threaded locals, at one point or another it breaks as some
 code don't like wrapped values. Since django is fundamentally broken when
 it comes to multitenancy I suggest to people that really need it and that
 can afford single-thread installations to simply modify settings on the
 fly. It's frowned upon but other solutions are just as bad.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/15089#comment:36>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to