Hi.
Django doesn't use connection pooling. That's beyond scope of Django.
Normally Django opens connection per worker thread and keeps it open as
long as there is no unrecovable error or connection exceeds MAX_AGE setting
See
https://docs.djangoproject.com/en/1.11/ref/databases/#connection-manag
Am Freitag, 21. Juli 2017 19:55:17 UTC+2 schrieb Fred Stluka:
>
> Answer: Connection pooling
>
> Sharing a single DB user for all/multiple Web app users allows
> connection pooling. Otherwise, you have to create a new DB
> connection for each HTTP request, or at least for each web app
> user.
Hi,
I think connection pooling is out of Django scope. Django though reuses db
connection. In some early versions Django opened and closed connection per
request.
21.7.2017 20.55 "Fred Stluka" kirjoitti:
> Answer: Connection pooling
>
> Sharing a single DB user for all/multiple Web app users
Answer: Connection pooling
Sharing a single DB user for all/multiple Web app users allows
connection pooling. Otherwise, you have to create a new DB
connection for each HTTP request, or at least for each web app
user. Creating DB connections is relatively slow.
Am Donnerstag, 13. Juli 2017 10:32:26 UTC+2 schrieb Antonis Christofides:
>
> BTW,
>
> another idea for "connecting" to PostgreSQL as different users would be to
> actually have Django connect to PostgreSQL as a superuser and then
> (probably in some early middleware) execute SET SESSION AUTHOR
BTW,
another idea for "connecting" to PostgreSQL as different users would be to
actually have Django connect to PostgreSQL as a superuser and then (probably in
some early middleware) execute SET SESSION AUTHORIZATION to switch permissions.
This is probably easier and more robust and it's easier to
Just for the records, I found a blog post how to use row level security in
postgres with one application db-user:
https://blog.2ndquadrant.com/application-users-vs-row-level-security/
Here is the essential code:
SET my.username = 'tomas'
CREATE POLICY chat_policy ON chat
USING (current_set
Thank you for your answer. Yes, I use one database user since several
years, and I guess it will be that way the next years.
Nevertheless I think it is good to talk about things like this from time to
time.
Regards,
Thomas
Am Dienstag, 11. Juli 2017 12:11:59 UTC+2 schrieb Antonis Christofide
Am Dienstag, 11. Juli 2017 11:46:41 UTC+2 schrieb Avraham Serour:
>
> Where would you store the password hashes?
>
>
I see several possible ways.
1. use django.contrib.auth for authentication like before. The initial
connection to the db gets done via a database-superuser. After auth in
djang
Hi,
This was discussed three months ago (the subject was "DATABASE DICTIONARY in
Settings.py"), and this was my opinion:
As you know, RDBMS's keep their own list of users and have sophisticated
permissions systems with which different users have different permissions on
different tabl
Where would you store the password hashes?
This would mean that no data ever could have relations between users
On Tue, Jul 11, 2017 at 12:40 PM, guettli wrote:
> I guess most applications have exactly one database user.
>
> Why not use one database for each application user?
>
> Example: User
I guess most applications have exactly one database user.
Why not use one database for each application user?
Example: User "foo" in my web application has a corresponding database user
"foo".
This way you could use row level security from the database.
PostgreSQL has a lot of interesting feat
12 matches
Mail list logo
