Kristian Waagan <[email protected]> writes: > Hi, > > While writing a test for new functionality in the istat daemon I > stumbled across a problem with the DatabaseMetaDataTest (DMDT), which > is being run as part of the upgrade tests. > > The problem is that my new test causes entries to be added to various > system tables, for instance SYSFOREIGNKEYS. These rows interfere with > the metadata tests, causing failures. These rows have to exist during > several of the upgrade phases, including those where DMDT is being > run. > I'm assuming disabling DMDT isn't an option. > > Does anyone have any good ideas on how to fix this problem? > > In my opinion, a fix should be done to DMDT to avoid that other tests > have to care about what DMDT does. > I've tried to change DMDT to operate on its own schema, and that > works.
Using a separate schema sounds like a reasonable way to separate between DatabaseMetaDataTest's own data and the data of the other tests that run as part of the upgrade suite. > However, I may have altered some of the metadata searches doing > that, and it required a fair amount of changes to the test (see the > attached patch). The only queries that change, as far as I can tell, are some calls to getExportedKeys() and getCrossReference() that used to search all schemas, and now limit the search to the schema in which the test runs. They probably still test what they originally intended to test, but maybe we should at least add tests that exercise the code (call the methods with the schema parameter set to null and do some light verification of the result). Just for good measure. By the way, could perhaps a ChangeUserSetup be used with a user name that matches the desired schema name? That might simplify setup and connection initialization, as the user's schema should be set and created automatically. -- Knut Anders
