> In my experience such simple behavior is rarely needed. When you > actually need a pool it means that your app become pretty large so it > requires not only static pool but also other settings like minimum spare > connections, maximum spare connections, keep-alive timeouts etc... So > this becomes a complex matter in itself and I'd rather Django not to > reinvent this.
What about cases where running an external connection pooler is not an option, such as shared hosting environments? > For me this is very similar to the recommendation to use memcached as a > cache backend instead of mimicking its rich functionality inside Django. But django still implements file/database/memory caching that does not require memcached. Recommending a particular setup as "best practice" is fine and good, but there should be alternatives for those who can't use or don't need the "recommended" setup. Ideally, it seems django should offer simple connection pooling with 2 options: number of connections and an on/off switch. That would satisfy the needs of some/most, and for those that need something more robust, look into an external pooler. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
