On Fri, Oct 16, 2009 at 23:30, Michael P. Jung wrote:
> 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
>
James Bennett wrote:
> Setting aside async concerns, making the request available implicitly
> would be both counter to that overall design (and I'm very much a fan
> of that design, and I suspect its simplicity and understandability is
> part of why Django's popular), and feels like an attempt
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
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote:
> So I wonder what would be wrong with putting the request object in a
> threading.local object. It would neither kill performance nor cause a
> poor architecture by itself.
What's wrong, to me, is that it's a code smell
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote:
> mp> I've found it to be way more practical to just store the request object
> mp> inside a threading.local object and let my functions access it directly.
> mp> (...)
>
> Alex> Quite simply, no. Storing anything
Hi Alex,
mp> I've found it to be way more practical to just store the request object
mp> inside a threading.local object and let my functions access it directly.
mp> (...)
Alex> Quite simply, no. Storing anything in a threadlocal instead of
Alex> passing it around is indicative of bad coding