Currently, the core handlers (modpython.py and wsgi.py in
django/core/handlers/) wrap the main request handling in a
try/finally, where the "finally" part closes the database connection.
Obviously, this couples the handler to a database connection, which is
not ideal, because people should be able
On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Currently, the core handlers (modpython.py and wsgi.py in
> django/core/handlers/) wrap the main request handling in a
> try/finally, where the "finally" part closes the database connection.
> Obviously, this couples the handler to a data
>However, if a person *does* use a database, we still want that
>connection.close() in a finally.
Adapt my idea of middleware for database transaction handling :-)
Essentially if you have code outside the web app context, you handle
stuff yourself. But if you are running a web application, you j
On 16 Dec 2005, at 09:59, hugo wrote:
But if you are running a web application, you just hook
up a middleware that opens a cursor on process_request and commits or
rolls back that cursor on process_response (if the user did handle his
transaction himself, it won't matter - the data will be co
>This makes the assumption (currently inherent in Django) that you
>will only use one database connection. This can cause problems if you
>need to scale your application.
Actually it only makes the assumption that it is a common case that you
only manage one connection. There is nothing that woul
Simon Willison wrote:
>
>
> On 16 Dec 2005, at 09:59, hugo wrote:
>
>> But if you are running a web application, you just hook
>> up a middleware that opens a cursor on process_request and commits or
>> rolls back that cursor on process_response (if the user did handle his
>> transaction himse
+1
On 12/16/05, hugo <[EMAIL PROTECTED]> wrote:
>
> >However, if a person *does* use a database, we still want that
> >connection.close() in a finally.
>
> Adapt my idea of middleware for database transaction handling :-)
>
> Essentially if you have code outside the web app context, you handle
> s
On 12/17/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Adding orm hints for replication and for federation is going to be
> interesting, shall we say ;-)
>
>
a connection list each specifying a specific connection. (with a default one)
your could then override a the 'READ' connection wit
