Django design decision for multiple databases - django

I have two a django site, on some of the pages data is coming from a postgresql database. Another set of pages are connected to a sqlite database. The tables are from two different sources so I cannot merge them but I need to merge them in one django site. What is the best practice for this:
should I merge the two in a django application so modifiying model.py,views.. or I should put them into different django applications with different models, view ?

You can merge two apps into one instance, but then you won't be able to use default session and auth modules from django with models of one of it.
Good solution is to merge it into one project (so two apps can share some code and maybe some settings) but run it as 2 separate instances with 2 different settings loaded.
Also: you can just merge two databases, even if they are using different engines. Django has built in dumpdata and loaddata manage commands, you can use it to move data from one database to another.

Related

Django multiple Project using same database tables

I've been reading through related articles regarding using same database for multiple django projects however, I have not been able to come up with a fix yet.
I've tried relative and absolute pathing when importing but it gives "attempted relative import beyond top-level package" error when I try to access parent directory.
Project 1 gets the users to write to database by filling in a form and Project 2 retrieves data written in by users from database.
I'm using Postgresql for database. I've tried writing exactly same models.py for both projects but it seems like in database they appear as separate relations/tables. E.g. for table named school in both models.py, it would look like project1_school and project2_school in Postgres database.
Is there a way to write to and read from same tables of same database?
Thank you so much in advance.
I think that you might be confuse with the difference between Projects and Applications.
Projects vs. apps
What’s the difference between a project and an app? An app is a Web application that does something – e.g., a Weblog system, a database of public records or a small poll app. A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.
Writing your first Django app, part 1
So in you particular case, I would say that your actual projects, both of them, could be applications of one project. The main reason, why I think this is a better approach, is that both are gonna use the same data, one application writes while the other retrieve it. One could even argue that they actually could be the same application. But this may depend on many factors of your business.
BTW, is really hard for me to imagine a situation where it would be a good idea to have two projects using the same database. Even if both projects need to share data, I would not think in using on database. I would try to solve it at an application level. But I you need for some reason to share information at database level, there are tools to connect both databases.

Django two projects, same database

I try to set up two projects,
The first is a management project - it involves auth_user, sessions, writing to db.
The second project is a "serve content" project, it only read from the db, uses no sessions, users..
It rely on db data created in the first project, but does not change it.
The second project urls will be accessed very frequently. That's why I want to seperate the projects, with different subdomaons, and two apache instances, giving the second one more "power" (processes in wsgi deamon conf).
So what should I share between the projects? Same settings? SECRET_KEY? Models?
I assume I should also remove session app.
Can I set django db to be in read only mode?

shared DB across django projects

Our product has a restful API and a server rendered app (the CMS). Both share the database. Both are written in django
The fields and the models needed in both are not mutually exclusive, there are some only particular to the API, some particular to the CMS, and some which are common.
My question is if I run migrations on one of the repos will they try to drop the fields that aren't present in the models of that particular repo, and needed by the other. Will running the migrations individually in both repos keep the database up to date and not pose a problem.
The only other valid option IMHO (besides merging projects) is turning off automation of Django migrations on common models (Meta.managed = False) and taking table creation & versioning into your own hands. You still can write migration scripts using django.db.migrations but makemigrations command won't do anything for these tables.
This was solved by using a schema migration tool external to Django's own. We use
yoyo migrations to migrate our schema now.
Will running the migrations individually in both repos keep the database up to
date and not pose a problem.
Unfortunately, no. As you suspected, changes in one will attempt to override the other.
The easiest thing to do is merge the two projects into one so this problem goes away entirely.
If this isn't an option, can the code be organised in such a way that both projects share the same models.py files? You could do this by perhaps having the models.py files and migrations folders only exist in one project. The second project could have a symlink across to each models.py file it uses. The trick (and the difficult part) will be to make sure you never create migrations for the app which uses the symlinks.
I think the best things to do would be to have one repo that contains all the fields. This project will be responsible to apply the migrations.
In the other projects, you'll need a db_router containing a function allow_migrate which will return False on your model classes.
Also having different db user with different db permissions can prevent from altering the tables.

Where to put caching functions in Django?

Whenever I update the SQL database, I also update the Redis cache. Should I put all the Redis logic in models or should I have a new module for that?
Create a caching module to keep your cache logic together.
I prefer to keep my modules in a consistent structure based on how I organise the models module.
So if models contains car.py and driver.py I'd have those same files in my cache, forms & views modules. Makes it easier to find everything :)

Two Django projects with common models and business logic

I have two Django Projects that have different use cases. There are reached using different domains. They are hosted in two different servers. Also each Django project has it's own database.
Now, both the projects have some models and some business logic common between them. I don't want to duplicate the code and data which shall be chaotic going forward. Also, I want the models and code (business logic) to be in sync (when models/code is altered).
Can anyone guide me towards a pattern that can help me attain the required architecture: 2 separate projects with common models and business logic.
Thanks in advance.
I've done this before. You will have to move the shared models and business into a new python package (better if you can create a django app that encapsulates these models), in a separate directory.
Add this directory to your python path (the one that contains the package, not the package itself) and you should be able to use this code from within your projects.
The only downside to this is having to configure PYTHON_PATH in your servers or having to copy manually this package into your runtimes