Re: contrib.sites and multitenancy

This is the stuff I've come up on first try few days ago: Here is my current cache implementation: https://gist.github.com/795135 And here is my middleware: https://gist.github.com/795138 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: contrib.sites and multitenancy

Hi! I've started another thread since I was oblivious about this one. One thing I noticed in my early experimentation is that caching Site objects is a bit of waste. I don't know what is the overhead for caching Site objects compared to just IDs but I suppose when we get to hunderds of sites and

Re: contrib.sites and multitenancy

Carl and I had a long discussion in IRC about all the issues he raises above. I am still digesting that conversation, but there are some things that already spring to mind. 1. I can see the merits of defining a SITE_BACKEND api that would allow users to choose from different site-retrieval

Re: contrib.sites and multitenancy

On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote: > > 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

Re: contrib.sites and multitenancy

Thanks legutierr for all your work on this ticket and patch, and everyone for the comments. I just took some time to review the patch on #15089 and had a long conversation on IRC with legutierr, and here's what I'm thinking: It does appear that there is some code (CurrentSiteManager, for

Re: contrib.sites and multitenancy

To complement the above list of locations where Site.objects.get_current is still in use, I have generated the following list of locations in the code where settings.SITE_ID continues to be in use: $ grep -nr SITE_ID * | grep -v svn | grep -v pyc conf/project_template/settings.py:39:SITE_ID = 1

Re: contrib.sites and multitenancy

I have added an initial, incomplete patch to the ticket for anyone who would like to comment on it: http://code.djangoproject.com/ticket/15089 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: contrib.sites and multitenancy

I have been researching changes required to implement this, and I thought I would share one of the sticky points. Some of this is relevant to Gabriel's recent post. I have been reading through revisions 14141 [1] and 14142 [2], which reversed some of the changes in revision 13980 [3], and I have

Re: contrib.sites and multitenancy

I would be more in favor of seeing a new setting to configure `get_current_site()` than seeing the existing `SITE_ID` setting shoehorned into a new purpose (and being permanently misnamed for legacy reasons). For the sake of allowing complete customization of the site lookup process I suppose

Re: contrib.sites and multitenancy

Hi Carl, Russell, 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.

Re: contrib.sites and multitenancy

On 21/11/2010, at 12:41 PM, Carl Meyer wrote: > 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

contrib.sites and multitenancy

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. First, let me make a quick distinction between static and dynamic multitenancy. In the static case, you have a limited set of sites running on