#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 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
> 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 you API requires a Site, pass in a Site object where needed.
> 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.
> - 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.
> - 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?!
> `get_current_site()` would need to be swappable just like `KEY_FUNCTION`
for the cache framework, so people can define their own switching logic.
That was part of my proposal.
--
Ticket URL: <https://code.djangoproject.com/ticket/15089#comment:47>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
