Hello,
Il 03/04/2014 00:15, Russell Keith-Magee ha scritto:
On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti
<riccardo.magliocche...@gmail.com
<mailto:riccardo.magliocche...@gmail.com>> wrote:
Hi everyone,
i'd like to start a discussion about multi tenancy on this list.
I've been asked to move the discussion here by Aymeric in this ticket:
https://code.djangoproject.__com/ticket/17802
<https://code.djangoproject.com/ticket/17802>
First we already have an initial patch sitting in this ticket:
https://code.djangoproject.__com/ticket/15089
<https://code.djangoproject.com/ticket/15089>
patch here:
https://code.djangoproject.__com/attachment/ticket/15089/__15089-missing-site_id.diff
<https://code.djangoproject.com/attachment/ticket/15089/15089-missing-site_id.diff>
The patch basically change the SiteManager to return a Site based on
the request instead of the hardcoded settings.SITE_ID. Which while
useful for my usage is also making ticket 17802 obsolete since in
the mean time Sitemap has been switched to using get_current_site.
Another missing bit is having the request available everywhere, one
solution is to store in thread local storage that could be done
easily in a middleware without touching django core.
-1. Not. Going. To. Happen.
Search the archives of Django Developers if you want to know why. This
has been discussed to death.
Short version - it doesn't matter what pretty name you put on it, a
thread local is a global variable. We teach first year programmers not
to use globals, so why would we introduce them to Django as a core
framework idea?
I expected that :) i meant that if one wants that this can be done
without touching django at all.
Another interesting thing (to me at least) would be being able to
use a different model for the Site so one can stores some site
specific configuration there (keeping in mind that in the patch
sites return but get_current_site are cached).
That could be obtained through this patch:
https://github.com/apollo13/__django/compare/ticket15089
<https://github.com/apollo13/django/compare/ticket15089>
or maybe like what is done for the custom User model.
What's the use case here? What additional data do you want to track?
For an ecommerce site "prices are without vat", "you need a vat id to
register", something like that. Again this would nice but since one can
use a separate model that's not a showstopper.
There's some more features for full multi tenancy listed here
https://code.djangoproject.__com/ticket/15089#comment:36
<https://code.djangoproject.com/ticket/15089#comment:36>
but the above will suffice for my usage so i will not dig into it.
Broadly speaking the approach you've described in #17802 makes sense to
me - that is, find somewhere where the request is needed, and make sure
it's available. I haven't dug in to the full consequences of introducing
the request where you've put it, but the broad strokes look right.
I was on the "add the request everywhere camp" until i've seen the
15089-missing-site_id.diff patch. Lot of places have been converted to
get_current_site so with the patch applied a site aware site would come
for free. Let me mention that this does not change default behaviour.
Unfortunately, we're not going to rush into something here - once we add
or change an API, we need to support it, and we are committing to not
changing it - so before we make any changes, we need to make sure we're
not backing ourselves into a corner. That means solving the general
problem (or at least having an idea how we would address the general
problem), not just one small part of the problem.
The other approach that you haven't made mention of - Use a different
sites app altogether. Django's sites module isn't well designed for true
multi tenancy of the type that you're describing. However, it's also a
contrib app -- so it's entirely optional, and also replaceable. If you
have a specific set of requirements for multi tenancy, then write your
own third-party app to implement those changes, and use it.
It's entirely optional but lot of other contrib code knows about it
(grep get_current_site). So using something else would be quite painful
if you want to reuse other apps.
Also - Not Going to Happen. 1.7 beta has been released, so the window
for new features is closed. The best you can hope for at this point is
for inclusion in Django 1.8.
Yeah, thought about that after hitting enter :)
thanks,
riccardo
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/533D11F0.7030605%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
