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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
