Multi-tenant Django

[Alec Taylor]

Dear Django-developers,

I've been using Django for a few months now, and recently—for
different projects—started using the web-framework: web2py[1], and the
Django project: mezzanine[2].

Both advertise as being multi-tenant solutions[3][4].

Would it be possible to extend Django to meet this use-case? — Or have
I overlooked something and is this possible already?

Thanks for all information,

Alec Taylor

[1] http://www.web2py.com/
[2] http://mezzanine.jupo.org/
[3] https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw
[4] PyCon 2012 talk: http://youtu.be/M5IPlMe83yI?t=5m32s
http://dl.dropbox.com/u/18065445/Slides/PySFTalkSlides.pdf (slide42,
see yt for more info)

[Aymeric Augustin]

Hi Alec,

This is tracked in https://code.djangoproject.com/ticket/15089, isn't it?

Best regards,

--
Aymeric.

> --
> 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.
>

[Brett H]

Alec,

Mezzanine is using standard django.contrib.sites. Nothing special
there. The main issue with the sites framework is that each site runs
using a separate process and settings, so the resources can add up
depending on how you setup the stack, and managing the tenants becomes
the issue as they grow in number. Apache with modwsgi using self
destructing daemons is the best solution here.

Until https://code.djangoproject.com/ticket/15089 is resolved IMHO
django-hosts is currently the best lightweight solution for multi-
tenancy requirements in django, but not useful with a project like
Mezzanine I'm afraid.

https://github.com/ennio/django-hosts

cheers,

Brett

[Anthony Briggs]

Hi Alec,

One of the science experiments on my todo list is to try and set up one of the fancy new database routers (possibly with get_current_site() or similar) and see if I can serve multiple sites+databases from the same Django instance.

Not sure if that helps, or even it it'll work, but if it does it might do what you need.

Cheers,

Anthony

[Alec Taylor]

Thanks Anthony,

Looking forward to seeing your results :)

[charettes]

Using django-hosts I managed to put together a simple setup that maps subdomains to databases.

First, I have a default database with a table mapping sudomains to database name and a middleware that tries to load the correct object based on the match provided by django-hosts.

In my settings I have a placeholder database that gets replaced by the middleware if the subdomain is mapping to a database.

Finally I have a database router that returns the placeholder db alias when models are subdomain specific.

This setup is working pretty well so far.

Hope it helps!

Le mardi 15 mai 2012 05:30:28 UTC-4, Anthony Briggs a écrit :

Hi Alec,

One of the science experiments on my todo list is to try and set up one of the fancy new database routers (possibly with get_current_site() or similar) and see if I can serve multiple sites+databases from the same Django instance.

Not sure if that helps, or even it it'll work, but if it does it might do what you need.

Cheers,

Anthony

On 9 May 2012 13:02, Alec Taylor <alec.t...@gmail.com> wrote:

Dear Django-developers,

I've been using Django for a few months now, and recently—for
different projects—started using the web-framework: web2py[1], and the
Django project: mezzanine[2].

Both advertise as being multi-tenant solutions[3][4].

Would it be possible to extend Django to meet this use-case? — Or have
I overlooked something and is this possible already?

Thanks for all information,

Alec Taylor

[1] http://www.web2py.com/
[2] http://mezzanine.jupo.org/
[3] https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw
[4] PyCon 2012 talk: http://youtu.be/M5IPlMe83yI?t=5m32s
http://dl.dropbox.com/u/18065445/Slides/PySFTalkSlides.pdf (slide42,
see yt for more info)

--
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+unsubscribe@googlegroups.com.

[Anssi Kääriäinen]

On May 16, 12:18 am, charettes <charett...@gmail.com> wrote:
> Using django-hosts I managed to put together a simple setup that maps
> subdomains to databases.
>
> First, I have a default database with a table mapping sudomains to database
> name and a middleware that tries to load the correct object based on the
> match provided by django-hosts.
>

> In my settings I have a *placeholder* database that gets replaced by the

> middleware if the subdomain is mapping to a database.
>

> Finally I have a database router that returns the *placeholder* db alias

> when models are subdomain specific.
>
> This setup is working pretty well so far.

How to implement "database per client" is a commonly asked questions
in django-users. So, if you have something to share I think there
would be interested users.

Note that what you have done above will work only in 1.4+. In 1.3 the
connections dictionary wasn't thread-local object, and thus you are
changing the placeholder database for all threads - not just the
currently running thread.

- Anssi

[Bernardo Pires]

Hello guys,

Have you guys taken a look at  https://github.com/phugoid/django-simple-multitenant?

I'm not a big fan of one database per tenant as I think this can get quite out of hand very easily (migrating models on every single database). The app linked above simply adds a foreign key to all models needed, so that you can infer which Tenant you are talking about. I've been thinking of using it on my next project. Any suggestions? Thanks in advance.

Bernardo Pires

[charettes]

The "migrating models on every database issue" can be solved easily by creating a command that calls the specified one using `call_command` and passing the correct `db` kwarg to the underlying one.

Say you have installed South and want to call the `migrate` with two underlying dbs.

./manage.py multidbwrappercmd migrate --all

Would internally do:

call_command('migrate', all=true, db='db1')
call_command('migrate', all=true, db='db2')

[Anthony Briggs]

I did a similar thing for some of my projects - the problem is that you can't reuse any non-multitenant apps without hacking the multitenant stuff in first, ie. it's a bit of a hack, plus it makes things harder to maintain going forwards.

One database per tenant should (in theory) make life much simpler.

Anthony

--

You received this message because you are subscribed to the Google Groups "Django developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/xu90OdufzBkJ.

To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.

[Josh Cartmell]

I wanted to point out that Mezzanine doesn't actually just use
django.contrib.sites. Mezzanine uses django.contrib.sites and thread
locals. The way it is set up example1.com and example2.com can both
be driven by the exact same django instance but have different
content. The third paragraph in the first post of this thread
explains a bit more about how it works:
http://groups.google.com/group/mezzanine-users/browse_thread/thread/e173dee4c683e05c

On May 9, 8:15 pm, Brett H <brett.hay...@gmail.com> wrote:
> Alec,
>
> Mezzanine is using standard django.contrib.sites. Nothing special
> there. The main issue with the sites framework is that each site runs
> using a separate process and settings, so the resources can add up
> depending on how you setup the stack, and managing the tenants becomes
> the issue as they grow in number. Apache with modwsgi using self
> destructing daemons is the best solution here.
>

> Untilhttps://code.djangoproject.com/ticket/15089is resolved IMHO

> django-hosts is currently the best lightweight solution for multi-
> tenancy requirements in django, but not useful with a project like
> Mezzanine I'm afraid.
>
> https://github.com/ennio/django-hosts
>
> cheers,
>
> Brett
>
> On May 9, 1:02 pm, Alec Taylor <alec.tayl...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Dear Django-developers,
>
> > I've been using Django for a few months now, and recently—for
> > different projects—started using the web-framework: web2py[1], and the
> > Django project: mezzanine[2].
>
> > Both advertise as being multi-tenant solutions[3][4].
>
> > Would it be possible to extend Django to meet this use-case? — Or have
> > I overlooked something and is this possible already?
>
> > Thanks for all information,
>
> > Alec Taylor
>
> > [1]http://www.web2py.com/
> > [2]http://mezzanine.jupo.org/
> > [3]https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw

> > [4] PyCon 2012 talk:http://youtu.be/M5IPlMe83yI?t=5m32shttp://dl.dropbox.com/u/18065445/S...,

[Anssi Kääriäinen]

On May 23, 3:16 am, Anthony Briggs <anthony.bri...@gmail.com> wrote:
> I did a similar thing for some of my projects - the problem is that you
> can't reuse any non-multitenant apps without hacking the multitenant stuff
> in first, ie. it's a bit of a hack, plus it makes things harder to maintain
> going forwards.
>
> One database per tenant should (in theory) make life much simpler.

One schema per tenant would also be pretty good. It makes it much
easier to do cross-db queries, or use a public schema for common
stuff. This should be doable if/when the support for database schemas
is included. I got pretty far in that feature in ticket #6148, but it
turns out to be pretty complex to support introspection and creation
on all the databases for both production and testing. So, it remains
to see if we want to add all that complexity. Still, multitenancy
support seems to be one use case where the database schemas support
could be very useful in Django.

- Anssi

[schinckel]

I played around a bit with using this, and got something quite workable going on.

https://bitbucket.org/schinckel/django-multi-schema

It's really only an exploration, but does show that it can be done.

The problems actually really only got hard once you factor south into the equation.

There are a few little hacky things that needed to be done (like setting the search path),

and it probably only works on postgres, but as a concept I still feel like it has legs.

There are also a couple of other approaches out there, too.

Matt.

[Caleb Lamb]

Hi Alec,

Have you been able to find a multi-tenant solution for django?

Thanks,

Caleb