Re: Much the same code, different businesses

Doug,

Many thanks for your response. I'm leaning towards your 3rd option,
initially using subdomains rather than full domain names for each
business.

Best wishes,

Nick

On Mar 27, 10:48 am, Doug Ballance <dball...@gmail.com> wrote:
> There are a few choices that I'm familiar with.
>
> 1) Create a separate project/settings file for each of your stores,
> overriding templates as needed by placing assigning a template path
> for the project.  I think this is pretty much the recommended way to
> do things, especially if the number of sites are reasonably small.  It
> offers great data isolation (using a different database for each), and
> it allows you to use all kinds of django apps and plugins.  For mass
> hosting, this is going to require more resources since you'll have
> workers for each site rather than a shared pool of workers.
>
> 2) Do some 'strange things', such as changing database or schema on a
> per-request basis using threadlocals and a middleware. This offers
> much of the capability of 1, but there may be compatibility issues
> (module level caching for example) and tricky foreignkey
> restrictions.    http://tidbids.posterous.com/saas-with-django-and-postgresql
> That post, and some of the comments will probably be of interest to
> you.
>
> 2) Do your own multi-tenant user setup.  There isn't anything built in
> for this, and as a result you lose a lot of the built in functionality
> like the admin as well as any hope of using user aware third-party
> apps.  This is the way I ended up going.  We use a custom template
> loader/middleware to check for site specific templates, site specific
> caching, and a custom siteuser/site framework.  All data is stored in
> the same database, with ownership linked back to the custom siteusers/
> sites and permission checking related to the views.  We keep the
> django user and sites framework as well, but use it/the admin for
> administration use only.  This is the most complicated path, but I
> think the advantages make it worth it for a large number of sites. We
> can add sites using an admin interface, and use fewer resources since
> caching and workers are all shared.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.