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" <[email protected]> kirjoitti: > 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. > > At least, I learned this reason 20 years ago, and assume it is > still true. On the other hand, I've never checked to see whether > Django uses a connection pool by default, and it seems pretty > quick. > > Does Django use a connection pool? > > --Fred > ------------------------------ > Fred Stluka -- mailto:[email protected] <[email protected]> -- > http://bristle.com/~fred/ > Bristle Software, Inc -- http://bristle.com -- Glad to be of service! > Open Source: Without walls and fences, we need no Windows or Gates. > ------------------------------ > > On 7/11/17 6:10 AM, Antonis Christofides wrote: > > 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 tables. This is particularly useful in desktop applications > that connect directly to the database. Web applications changed that. > Instead of the RDBMS managing the users and their permissions, we have a > single RDBMS user as which Django connects to the RDBMS, and this user has > full permissions on the database. The actual users and their permissions > are managed by Django itself (more precisely, by the included Django app > django.contrib.auth), using database tables created by Django. What a user > can or cannot do is decided by Django, not by the RDBMS. This is a pity > because django.contrib.auth (or the equivalent in other web frameworks) > largely duplicates functionality that already exists in the RDBMS, and > because having the RDBMS check the permissions is more robust and more > secure. I believe that the reason web frameworks were developed this way is > independence from any specific RDBMS, but I don't really know. > > So the canonical way of working is to have a single *database user* as > which Django logs on to the database, with full permissions on the database > (including permission to create and delete tables), and many *Django > users*, each one with different permissions. Typically only one Django > superuser is created. I call the superuser "admin", which I believe is the > common practice. > > You can probably do things differently, and maybe there exist custom > database backends that would allow you to switch the database user on > login, but if there's no compelling reason you should really stick to the > canonical way. > > Regards, > > Antonis > > Antonis Christofideshttp://djangodeployment.com > > > On 2017-07-11 12:40, guettli wrote: > > 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 features: https://www.postgresql.org/ > docs/devel/static/ddl-rowsecurity.html > > Use case: Show me all items which user "foo" is allowed to see. > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/7d1eaa8c-d80a-4390-aaf9-8a95d3fcf6b4%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/7d1eaa8c-d80a-4390-aaf9-8a95d3fcf6b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/31981958-2d3e-6c02-eb57-0817676be6d0% > 40djangodeployment.com > <https://groups.google.com/d/msgid/django-users/31981958-2d3e-6c02-eb57-0817676be6d0%40djangodeployment.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/35fea627-eda0-3228-4e12-621444b931b9%40bristle.com > <https://groups.google.com/d/msgid/django-users/35fea627-eda0-3228-4e12-621444b931b9%40bristle.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHn91odqaqvHpAYP2hcuqNBCi49WZS-1-QaGTtDH%3DFfoiW79rw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
