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 himself, it won't matter - the data will be committed or >> rolled back already, so the remaining transaction would be empty) and >> can close the database then. > > > 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. Once you've scaled as far as you can with > replication (something I am very keen for Django to support) the next > step is to move to federation / sharding, where your data is split over > multiple databases (users 1-1,000,000 on server 1, users > 1,000,000-2,000,000 on server 2 etc). If you do that, you frequently > need to connect to more than one database during a single request > handling cycle. > > Cheers, > > Simon > >
I don't quite understand what more this would need from a middleware than being aware of all the cursors used within an http request. TBH, I think this is better handled with events, but anyway. Adding orm hints for replication and for federation is going to be.... interesting, shall we say ;-)
