Hi all,
I've recently been exploring simple multitenancy options in Django
using contrib.sites, and have some thoughts on how core could make it
easier.
A few options for how such a hook could be implemented:
1a) Same as above, but reuse SITE_ID; i.e. it can either be an
integer, or a string path to a get_current_site function. It ends up a
bit misnamed.
I think any settings.py option will help us a lot,
but doesn't the overall solution mean that one would still need to
have the Site model installed even if we use our custom callable?
I'd also like if someone could explain correct interfaces and if we're
going to change them.
Isn't Site/RequestSite the only possible interface right now?
The more I thinking on it, the more I see we have the same problem
like with the Users model:
the only way to write reusable 3rd party app is to do item_site =
ForeignKey(Site) which bounds us to the Site object.
Also, will the request be passed to SITE_ID if it become a callable?
If not, I'd like if we take get_current_site(request) instead of
Site.get_current(), and deprecate the last one.
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Contrib.flatpages is an example
of this -- the flatpage model has an FK to Site, so it doesn't make
sense for flatpages to call a method which might return a Site object
or might return something else. It needs a real Site object. In my
mind, this use case is why deprecating Site.objects.get_current() is
not a good option.The current patch on #15089 deprecates
In my mind, the introduction of a multitenancy hook (in the 1.4
timeframe) could then look something like this:
* Add an optional "request" argument to Site.objects.get_current_site(). If
SITES_BACKEND is set and Site.objects.get_current() is not passed the
request, it's an error. But existing code, with no SITE_BACKEND,
continues to work fine calling Site.objects.get_current() with no
request.
* Both Site.objects.get_current() and get_current_site() call
SITE_BACKEND, if its set, and return whatever it returns.
Site.objects.get_current() should check this return value and error if
its not an instance of the Site model. get_current_site() doesn't care
what it returns.