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 discovered a couple of challenges. There are a number of places in contrib app code where the current site must be known, but where there is no request available to be passed to get_current_site() (contrib.sitemaps is the most important example, see below); in each of these cases, Site.objects.get_current() must be used. As Carl Meyer's above post so correctly described, Django as of version 1.2.4 is pretty good at "static multitenancy", but Django is very, very bad at "dynamic multitenancy" (i.e. true multitenancy). The problem is that dynamic multitenancy is determinable by the current request, whereas Django's entire multitenancy implementation is currently tied to a static global SITE_ID value, and is therefore locked into a static multitenancy mode. It is for this reason that Site.objects.get_current() needs to be deprecated. Site.objects.get_current() is 100% dependent on the global SITE_ID value, and as a result will never permit dynamic multitenancy to be implemented by any application that uses it. If the objective is to implement true multitenancy in Django using the sites framework, then the only alternative to eliminating Site.objects.get_current() in favor of get_current_site() would be to have Django store each request in thread locals, the way that Flask does [4]. In other words, in order to implement true multitenancy, either the request will have to be placed into thread locals so that it may be accessed by Site.objects.get_current(), or the request will have to be passed around to every corner of the code that needs to know about contrib.sites, so that it can be passed to get_current_site(). Now, maybe I am jumping to conclusions when I imply that using thread locals a la Flask [4] is not a viable option. Perhaps it would make sense to add a middleware that could manage thread locals data safely and provide an interface to access the stored request. It might be the easiest thing to do. But I for one do not think that it will be necessary to do so. PLEASE NOTE: the above referenced ticket does not NECESSARILY propose modifying every library that might have a dependency on Site.objects.get_current() [see below]. What this ticket is saying is that any applications that implement multitenancy in such a way that dynamic multitenancy is not an option should be modified during the 1.4 iteration so as to support dynamic/true multitenancy. It is also proposing a tangible implementation and interface that can be used to do so. The issues I am raising in this post can be delayed until future versions if need be, as long as a migration path is specified now. At least, those are my two cents. [1] http://www.google.com/url?sa=D&q=http://code.djangoproject.com/changeset/14141 [2] http://www.google.com/url?sa=D&q=http://code.djangoproject.com/changeset/14142 [3] http://www.google.com/url?sa=D&q=http://code.djangoproject.com/changeset/13980 [4] http://flask.pocoo.org/docs/design/#thread-locals The list of locations where Site.objects.get_current is still in use seems to be as follows: $ grep -nr get_current\( django/ | grep -v svn django/contrib/auth/tests/views.py:195: site = Site.objects.get_current() django/contrib/comments/feeds.py:12: self._site = Site.objects.get_current() django/contrib/comments/feeds.py:17: self._site = Site.objects.get_current() django/contrib/comments/feeds.py:22: self._site = Site.objects.get_current() django/contrib/comments/moderation.py:242: subject = '[%s] New comment posted on "%s"' % (Site.objects.get_current().name, django/contrib/sitemaps/__init__.py:33: current_site = Site.objects.get_current() django/contrib/sitemaps/__init__.py:68: site = Site.objects.get_current() django/contrib/sitemaps/__init__.py:89: current_site = Site.objects.get_current() django/contrib/sitemaps/tests/basic.py:166: Site.objects.get_current() django/contrib/sites/models.py:10: def get_current(self): django/contrib/sites/models.py:92: current_site = Site.objects.get_current() django/contrib/sites/tests.py:19: # Make sure that get_current() does not return a deleted Site object. django/contrib/sites/tests.py:20: s = Site.objects.get_current() django/contrib/sites/tests.py:28: site = Site.objects.get_current() django/contrib/sites/tests.py:33: site = Site.objects.get_current() django/views/decorators/cache.py:19: sites.get_current().domain, for example, as that is unique across a Django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
