#15089: contrib.sites and multitenancy
---------------------------------------------+------------------------------
Reporter: legutierr | Owner: nobody
Status: new | Milestone:
Component: Contrib apps | Version: 1.3-beta
Resolution: | Keywords:
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------+------------------------------
Comment (by carljm):
Replying to [comment:19 linovia]:
> It may sound a bit naive but why would we need the request object to get
the site ?
> I mean, urlconf management can be linked to a request, but the code
stores it within the local thread so that any reverse can be done without
explicitly giving the current request.
>
> Wouldn't it make sense to store the site id the same way the urlconfs
are handled and defaults it to a DEFAULT_SITE defined in the settings file
?
Yes, putting the request (or the request host, or a site id picked
dynamically in a middleware) into threadlocals would be one approach (in
fact, its the method currently chosen by third-party apps implementing
dynamic multitenancy for Django), but Django's philosophy has generally
been to minimize usage of threadlocals: if you need information from the
request, you should pass it in to where it's needed. Thus the effort here
to find a threadlocals-free approach if possible.
--
Ticket URL: <http://code.djangoproject.com/ticket/15089#comment:21>
Django <http://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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
