I'm using django with django-tenants for a SaaS app and it is using the user's subdomain to set the db schema in postgresql. So a call to user1.app.com will use the 'user1' schema.
Each call to a view creates a new database connection by default. If the view call ajax, a new connect/disconnect happens. Using this method works as each call gets it's postgresql search path set to the correct schema using the django-tenants middleware.
My question is if I set CONN_MAX_AGE to persist connections for a period of time to reduce the heavy connect/disconnect load on the server, will django pool connections from multiple users potentially using different schemas? I am concerned, because:
All users are using the 'default' DATABASE. (just the search path changes)
I don't see any logic that binds a connection to a unique user session.
The built in development server ignores the CONN_MAX_AGE setting so I can't test locally.
I have looked into the connection_created signal, but I would be duplicating logic with django-tenants and I'm not sure of any unintended consequences.
Using django 4.0.7 and posgresql 12.
Related
I built a Django project with a few models. Now I created a second server with the same setup. This one is meant to be the deployment server. Databases are separate from the dev-server.
However can you tell me if I can simply copy the databases from the dev server to the deploy or will the Django logic, since I also mean the user models and permissions etc.
The tables which I created myself are no problem to transfer to the new server. However I am wondering If Django gets confused when I also transfer something like the auth_user Model.
Should this work since I also just copied the backend logic as well?
To be more specific, I want to retrieve db setting from a config server when django project starts, and use it to setup django db connection
Someday in the future, the setting in the config server may be changed (for example, change the user password) and pushed to django project then reset the db connection, so I can use new setting without restarting django project or updating project code
Is there a way to do that?
Or what's the right way to hide the db sensitive information (password, etc) from django project code?
Any helps will be grateful, thanks~
Using Django (and DRF)
If I'm set ATOMIC_REQUESTS=True on the Database config, would this apply for signals as well?
I'm trying to understand if there is a chance our transaction is finished after response
I need to connect to a Postgresql server in my Django project. But I'm under strict instructions NOT to make any modifications to the database or tables.
If I'm not wrong, simply adding this DB to settings.py and running syncdb would create and add some django specific tables to the database.
How can I get around this issue? If I add another (local) sqlite DB to settings.py under default and my remote postresql server separately; can I be sure of Django not creating any tables in my server? I couldn't find this info in the documentation.
Thanks
Configure two databases in settings.py, and a create database router to route your queries to the appropriate database.
Route all the Django admin / users stuff to your sqlite database (make it the default database, and make sure that is indeed the one your router returns by default), and single out your application queries that need to go to the Postgres database.
Routers also have a method to locate a DB for writes and one for reads, so you can use this as a failsafe: just make sure db_for_write never returns your Postgres database, and you're good to go.
I have 2 instances of django application.
One is frontend - a normal wsgi app.
Another is backend - a twisted daemon running with ./manage.py rundaemon.
They share django settigns and models.
Now, when one of them has a query, it got cached.
And when another updates database - the cache will not be flushed.
That's obviously because they have no clue about another instance accessing the same database.
Is there a way to disable caching, or flush it manually and force query to be reexecuted?
(I guess the admin app does flush query caches somehow)
I'm not sure if this is the best solution, but it worked for me when I faced the same problem.
import django
django.db.connection.close()
The connection will automatically get reopened the next time it is needed.