Multiple Django projects using the same database

[Ien C.]

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  

[Russell Keith-Magee]

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 %-)

[Ien C.]

Thanks Russ!

Good point about the validation logic. Will definitely keep that in mind. And yes, my basic approach here is the same code base working on different subsets of data by default, with the ability for data to be optionally "seen" by both sites as needed.

One more question: there's no need to keep settings.SECRET_KEY the same across the sites, is there? In the context of this question, someone told me that SECRET_KEY is used for hashing db reads/writes, but that doesn't sound right to me and I don't see anything about that in the docs. The two sites can (and should) have different SECRET_KEY values, right?

All the best, Ien

[Russell Keith-Magee]

Depends on what your "secret" sharing policy is between the two sites. If you want a truly shared login (as in - log into site A, login is recognised on size B), or shared session payloads, you would need to have a shared SECRET_KEY (along with some other cookie domain tweaks). However, if they're independent sites, and you explicitly *want* someone to log into site A and site B separately, then different SECRET_KEYs are advisable.

I don't know what your "someone" meant about hashing db read/writes - unless they were referring to the session table. It certainly isn't something that is applied to *all* DB read/writes, or would prevent data written with one site from being read by the second.

Yours,

Russ Magee %-)

[Ien C.]

All makes sense, thanks again! --Ien

[Hammi]

Hi, other then the secret key, what should the two projects share ? i need to do this .. 

[sanjeev bhagat]

Apr 12

Hi, i am working on the same...

Sanju