Dan Nessett wrote:
Given this background, consider the following
(and feel free to comment
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
+ 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
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