On Thu, 2010-01-07 at 15:43 -0500, Francis J. Lacoste wrote: > On January 7, 2010, Guilherme Salgado wrote: > > As I explained earlier, to make the read-only mode switching > > transparent, I turned the main_master/slave config variables into > > properties of DatabaseConfig, which return either rw_main_* or > > ro_main_*, depending on the mode we're on. > > > > After our discussion we decided to cache the mode in the request so that > > we only look for the file once for each request (and, more importantly, > > it doesn't change mid-request). One small problem with that, though, is > > that DatabaseConfig.main_master is called in some contexts which don't > > have a request, so we need to cope with that. It doesn't sound like a > > show-stopper to me, but I'd like to know what you think. > > > > What are those context? If there is no concurrent possibility, then it's not > really an issue.
Scripts. ZopelessTransactionManager and sqlbase.connect (which is deprecated and only used in scripts). Another option would be to change them to use rw_main_master directly, since that's what they need. > > > Here's the utility we discussed, which deals with a missing request > > nicely: http://paste.ubuntu.com/353092/ > > > > I wouldn't make the request part of the utility. I'd let the call site handle > the request caching. The only responsibility of the utility is in monitoring > and logging the read-only state change. > We'll have a bunch of callsites for the utility (DatabaseConfig.main_master/slave, model/pofile.py, webapp/adapter.py, webapp/authorization.py, webapp/dbpolicy.py, and others), and nearly all of them would benefit from a cache in the request, so I'd rather do it in the utility. -- Guilherme Salgado <[email protected]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
