#15089: contrib.sites and multitenancy
-------------------------------+------------------------------------
Reporter: legutierr | Owner: apollo13
Type: New feature | Status: new
Component: contrib.sites | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by loic84):
Replying to [comment:47 apollo13]:
> Replying to [comment:45 loic84]:
> > If we are serious about having multi-tenancy in core, we need the
current site to be made a thread local and a first class citizen in `
BaseHandler .get_response()`, just like we do for URLCONF. Indeed,
`get_current_site()` and `get_urlconf()` are the two sides of the same
coin.
>
> Absolutely not. First of making the `BaseHandler` aware of the current
site would imply strong coupling of a contrib app to core -- that's an
absolute no-go. I also don't agree with the thread local, there is no need
imo to make it one, `User` for instance works fine without thread locals
Django completely ignores one of the main part of an URL (the domain),
it's a blatant omission in my opinion. Having a hook in place in
BaseHandler for people or apps that care about that portion of the URL is
not the same as strong coupling a contrib app. `contrib.sites` could
simply consume that hook.
> > There are plenty of areas of Django that need to be aware of the
current site and that aren't reached (most of the time for good reasons)
by the request object. The remaining uses of `Site.objects.get_current()`
in the codebase (instead of `get_current_site()`) hint at the problem.
>
> If your API requires a Site, pass in a Site object where needed.
I'm not talking about my own API, I'm taking about areas of Django over
which I have no control.
> > Particularly troublesome if the SITE_ID is only available in the
request:
> > - Declarative stuff like sitemaps, default values of model fields,
etc.
>
> I agree that this is a problem, but I don't think thread-locals are the
solution, especially since in the shell you don't have access to the
request either.
Indeed you don't, and that's why I don't want to keep the curent SITE_ID
in the request but in a thread local. In the shell you have control over
1. the settings, and 2. the env, so you could write `SITE_ID=2 ./manage.py
whatever`.
>
> > - Random methods that don't get the request as parameter even though
the calling method had access to it.
>
> That's a problem in the API, not in the sites stuff.
>
> > - Methods called from templates such as `get_absolute_url()`. Being
able to pass the request as a parameter to such methods is the main reason
I've been assessing Jinja2.
>
> RequestContext?!
What do you mean? Right now you are out of luck if you need your
`Model.get_absolute_url()` to be site-aware, for example to return a fully
qualified URL when the site for the current request is different than the
site to which your model instance belongs. I don't see how RequestContext
helps, even if the request is present in the template context, I won't be
able to pass it as an argument to `get_absolute_url`, so
`get_absolute_url` still has no idea about the current site.
--
Ticket URL: <https://code.djangoproject.com/ticket/15089#comment:48>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.e7a32f429c6403fa467497cffa6eee21%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
