On Fri, 17 Sep 2010 21:05:12 +0200, Platonides wrote: > Dan Nessett wrote: >> Given this background, consider the following (and feel free to comment >> on it): >> >> parserTests temporary table code: >> >> A fixed set of tables are specified in the code. parserTests creates >> temporary tables with the same name, but using a different static >> prefix. These tables are used for the parserTests run. >> >> Problems using this approach for selenium tests: >> >> + Selenium tests on extensions may require use of extension specific >> tables, the names of which cannot be elaborated in the code. > > The extensions could list their table names. No problem there. > > >> + Concurrent test runs of parserTests are not supported, since the >> temporary tables have fixed names and therefore concurrent writes to >> them by parallel test runs would cause interference. > > So it gets changed to a random name with a fixed prefix... What concerns > me is > >> + Clean up from aborted runs requires dropping fossil tables. But, if a >> previous run tested an extension with extension-specific tables, there >> is no way for a test of some other functionality to figure out which >> tables to drop. > > Run a script dropping all tables with a fixed prefix (the shared part of > the tests) when you have no tests running. > >> For these reasons, I don't think we can reuse the parserTests code. >> However, I am open to arguments to the contrary. > > There may be other issues with that code, and using a separate db would > be preferable if you have enough permissions, but this doesn't seem like > real problems. > > What concerns me is that Oracle is using (r58669) a different prefix for > the parsertests table. If it has some restriction on [medium-large] > table names, there may not be possible to run the tests there using the > long table names that we could produce.
The strategy you suggest is reasonable. But, I think it requires significant changes to the parserTests code. The question then is: is it simpler to modify this code or just write something new? -- -- Dan Nessett _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
