On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote: > 1. It's easier to "switch out" pooling utilities this way, or to > switch between pooling and not pooling as circumstances dictate. When > your framework tries to do connection pooling for you, it > automatically gets harder and, depending on whether you can turn the > framework's connection-pooling utility off, maybe even gets > impossible.
I've experienced the exact opposite. When I can say in a config file that I want 10 connections in a pool, that's a lot easier for me than setting up an external utility. Moreover, it works with whatever DB I happen to have configured my app to use at the time. > 2. Admittedly I don't have a whole lot of experience in the area, but > creating and managing a pool of connections to be passed from thread > to thread just feels like much more hassle and overhead than we really > need, especially since there are external pooling utilities available. It seems to me that it'd be better to discuss this at the technical level first and then worry about implementation afterward. I realize that the django devs are strapped for time, but that doesn't strike me as grounds for making everyone else solve the same problem over and over again. If it's determined that it is something that should be included in the ORM component, then maybe someone else will step up to the plate. -- Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
