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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
