#15089: contrib.sites and multitenancy
---------------------------------------------+------------------------------
Reporter: legutierr | Owner: nobody
Status: new | Milestone: 1.3
Component: Contrib apps | Version: 1.3-beta
Resolution: | Keywords: blocker
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Comment (by legutierr):
Thanks for your comments, Gabriel.
You write:
> ''Adding a Site.objects.get_site_for_id() method seems wholly
unnecessary just to avoid writing Site.objects.get(id=FOO) unless it has
some other handling built in which you haven't explained.''
The cacheing logic would be moved from Site.objects.get_current() to
Site.objects.get_site_for_id(). This way, the new implementation would be
computationally equivalent to the old implementation. The interfaces
would be re-factored, but the case where SITE_ID is used to retrieve the
site would still have the same underlying logic.
You write:
> ''Under the current system, if contrib.sites is installed but SITE_ID is
missing an error should be raised, it shouldn't fall back to doing a Site
object lookup based on the request automagically. Making SITE_ID an
optional (rather than required) setting for the Sites Framework isn't a
wholly trivial change and could easily confuse users''
There are just two ways to approach the precedence of SITE_ID vs. the
request in determining what site to retrieve. SITE_ID can act as a
default, or SITE_ID can act as the override. What you are suggesting,
making SITE_ID required, would force it to act as a default. Although
this is a viable option, of course, it seems less intuitive to me than
causing it to act as an override. Either way, the decision should be
about whether it is more intuitive for SITE_ID to be a default/fallback,
or for it to override whatever might be in the request. Also, I do not
see what would be automagical about using the request to lookup the site,
that's the whole point of this ticket.
You write:
> ''I'm -1 on adding a default_to_request_site parameter to
get_current_site(), though. The entire point of get_current_site() is that
it should always return a Site or !RequestSite (unless you've
misconfigured the Sites Framework). If third-party app authors require
that they always get back a Site object, then they should be doing lookups
using Site.objects directly.''
Given that among the proposed requirements is the idea that users should
be able to provide their own overriding SITE_CALLBACK method, which could
return anything at all, it seems futile to narrowly define
get_current_site() in terms of what types of objects it returns.
Nevertheless, it is important, I think, to enable 3rd party app designers
to be able to control whether or not the object they are receiving is an
ORM object.
In most cases, the third-party app will want to link to the ORM object
either via a !ForeignKey, or more likely (given that the specific class
cannot be ensured) through a generic relation. In few cases will a
!RequestSite or some other mock object be acceptable. Direct calls to
!SiteManager methods will also be problematic, for a number of reasons: if
SITE_CALLBACK is defined, the return value may not be a Site object;
direct calls to !SiteManager methods will circumvent the logic managing
the use of SITE_ID vs. the request in retrieving the Site object; a
central method is required in order to encourage consistency of approach.
Perhaps the correct name of this parameter is `require_orm_object` or
something like that, instead, given that it should also inform what is
returned by SITE_CALLBACK.
--
Ticket URL: <http://code.djangoproject.com/ticket/15089#comment:6>
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.
