On Sun, 19 Sep 2010 23:42:08 +0200, Platonides wrote: > Dan Nessett wrote: >> Platonides wrote: >>> Dan Nessett wrote: >>>>> What about memcached? >>>>> (that would be a key based on the original db name) >>>> >>>> The storage has to be persistent to accommodate wiki crashes (e.g., >>>> httpd crash, server OS crash, power outage). It might be possible to >>>> use memcachedb, but as far as I am aware that requires installing >>>> Berkeley DB, which complicated deployment. >>>> >>>> Why not employ the already installed DB software used by the wiki? >>>> That provides persistent storage and requires no additional software. >>> >>> My original idea was to use whatever ObjectCache the wiki used, but it >>> could be forced to use the db as backend (that's the objectcache >>> table). >> >> My familiarity with the ObjectCache is casual. I presume it holds data >> that is set on particular wiki access requests and that data is then >> used on subsequent requests to make them more efficient. If so, then >> using a common ObjectCache for all concurrent test runs would cause >> interference between them. To ensure such interference doesn't exist, >> we would need to switch in a per-test-run ObjectCache (which takes us >> back to the idea of using a per-test-run db, since the ObjectCache is >> implemented using the objectcache table). > > You load originaldb.objectcache, retrieve the specific configuration, > and switch into it. > For supporting many sumyltaneous configurations, the keyname could have > the instance (whatever that cookie is set to) appended, although those > dynamic configurations make me a bit nervous.
Well, this may work, but consider the following. A nightly build environment (and even a local developer test environment) tests the latest revision using a suite of regression tests. These tests exercise the same wiki code, each parametrized by: + Browser type (e.g., Firefox, IE, Safari, Opera) + Database (e.g., MySQL, Postgres, SQLite) + OS platform (e.g., Linux, BSD unix variant, Windows variant) A particular test environment may not support all permutations of these parameters (in particular a local developer environment may support only one OS), but the code mechanism for supporting the regression tests should. To ensure timely completion of these tests, they will almost certainly run concurrently. So, when a regression test runs, it must not only retrieve the configuration data associated with it, it must create a test run environment (e.g., a test db, a test images directory, test cache data). The creation of this test run environment requires an identifier somewhere so its resources may be reclaimed when the test run completes or after an abnormal end of the test run. Thus, the "originaldb" must not only hold configuration data with db keys identifying the particular test and its parameters, but also an identifier for the test run that can be used to reclaim resources if the test ends abnormally. The question is whether using a full wiki db for this purpose is advantageous or whether stripping out all of the other tables except the objectcache table is the best implementation strategy. -- -- Dan Nessett _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
