Sunday, March 29, 2015

Re: Multiple Django projects using the same database


On Mon, Mar 30, 2015 at 12:14 AM, Ien C. <ien@alum.mit.edu> wrote:
Hi everyone,

I'm hoping to confirm my understanding on how to deploy multiple Django websites using the same database, using postgres and gunicorn/nginx. 

Doing this seems to me as simple as:
1. Creating a copy of the Django project in its own directory, with its own settings.py etc.
2. Keep the same settings.DATABASES the same, i.e. pointing to the same postgres server.
3. Deploy the new site as if were a standalone site, e.g. separate /etc/nginx/sites-available/new-site-name.conf etc.

Of course doing the above wouldn't be very useful unless the two sites did something different. For instance, to have them by default work on different subsets of the data, I could use the Django sites framework, where the CurrentSiteManager restricts queries to data associated with the specific site baed on settings.SITE_ID. The two sites could still access all data using standard model managers, and there would be no problem having models associated with one site link to models from another site via related fields as normal, as long as the model's default manager could see all data.

Core Django tables like User and Permissions would be shared between the two sites, so if a user has access to one site, they will have access to the other site.

As for race conditions, there are no particular new issues raised by two sites sharing the same database, i.e. race conditions could happen but it's no different than with multiple requests on a single site.

Have I got all that right? Anything I'm missing? Is it really as simple as just having two Django sites point to the same database via settings.DATABASES?

Thanks,
Ien  

Hi Ien,

You've got it right - it's exactly that simple.

Remember, even if you've only deployed a single website, you're still going to have multiple threads/processes accessing that site - your web server is inherently multithreaded. All you're doing by deploying 2 sites is introducing a way by which half of those threads/processes will be using a different chunk of code to evaluate requests.

The only caveats you didn't cover that I can think of relate to inconsistencies in the two different sites interacting with the data in different ways. If you've got site logic that imposes validation conditions or something like that, and the two sites have different validation logic, there's no inherent guarantee that an object created on one site will meet the validation requirements of another. However if you make sure all the validation logic is common between the two sites, and the only thing that is different is the subset of data available, or the presentation style of that information, then you shouldn't hit this sort of problem.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-AhQ5HONF_tL56LD67_43KNuA2E-Aavx5f_-NmLNZmJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment