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