Jeremy Dunck wrote: > Alex just spent a bunch of time adding multi-db support; part of the > effort involved in that work was removing the > request=thread=connection assumption that tied django to a single DB.
Untying the database session from the request response cycle makes sense for multi-db applications. But imho there should always be a simple and convenient way of getting easy access to some kind of default database session. (As well as to the request object, no?) Cal Henderson in the Keynote "Why I Hate Django" pointed out in a very funny way that most projects never get THAT big that you need multi db support, partitioning, extensive database clusters, etc. Just skip to 19:20 to see his "scientific graph". I'm not saying that scalability does not matter. I'm saying that Django should not change the slogan from "for perfectionists with deadlines" to "for scale nerds with a PhD in software architecture". I love Django because it lets me get stuff done and not having to worry about dependency injection, sophisticated design patterns, etc. And if it ever gets into my way I can easily get around it and do stuff the hard way. Jeremy Dunck wrote: > But I'll side with Alex and say that a thread-local request is a bad > idea. In fact, people do use Django in async systems: > Old but useful here: http://code.google.com/p/django-on-twisted/ The use of twisted.web2 doesn't change the fact that one thread handles one request at a time. In order to do async I/O you either need highly sophisticated continuations, white threads or a complete different program structure. The less you want the user to care about async I/O the more the programming language and/or VM has to do heavy lifting which in turn slows things down. White threads (a Java feature) for example don't really speed up things compared to system threads as they're not lightweight. Stackless Python tries to solve this issue with so called Microthreads, but I've never used it, so I can't really judge if it's ready for production code. Guido once stated that he doesn't like Stackless Python, so I'm suspicious. Thread local objects are often considered evil, but as long as Django is aiming for the one-thread per request model I rather see them as a very practical way of scoping data on a per request basis. --mp --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
