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" <f...@bristle.com> 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:f...@bristle.com <f...@bristle.com> --
> 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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.

Reply via email to