On Fri, Jul 24, 2009 at 7:55 PM, Glenn Maynard<gl...@zewt.org> wrote: > There are lots of requests for ways to build specific types of > queries, too. You can't really commit a QuerySet method for one thing > and then...
So, let's walk through this logically. Suppose we start with a patch which does the sort of thing you apparently want: hold on to the connection, and reset it after each request/response cycle. That patch would never get committed, because it would have even worse side effects (see: "spinning up a server process ties up a DB handle for as long as the process lives?") and could quite realistically cause resource starvation. How do we avoid that? Well, we'd need some way to say "I'm done with this connection for now but I'll be needing a connection again soon, so hang on to it to avoid the overhead of re-establishing it". Which is pretty much the definition of connection pooling. So we see that this isn't a pointless slippery-slope argument: connection pooling is an inevitable outcome of your approach, just one you've yet to accept. But it gets worse: you'd want this mechanism to be independent of the web server processes/threads in which the connections are used, because you don't want to have to have one connection pool per server process (since that just reintroduces the problem of latency every time you spin one up and increases overhead and code complexity) and you don't want the connection pool to be killed if the process which hosted it gets recycled by the server. Which points to... an external connection-pooling utility. Such utilities already exist and are usable right now. They don't belong in Django (for many reasons, "don't reinvent the wheel" being only one of them). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
