db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: DatabaseMetaDataTest as part of the upgrade tests
Date Wed, 16 May 2012 06:00:47 GMT
On 15.05.12 17:33, Knut Anders Hatlen wrote:
> Kristian Waagan<kristian.waagan@oracle.com>  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.

Thanks for the comments, Knut Anders.

I've created DERBY-5764 ([1]) to track this work.

>> 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.

Adding a few additional tests to compensate for the lost coverage sounds 
like a good idea. I'll address this in a separate patch.

> 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.

Yes, that works nicely.
I was a bit unsure initially how the various decorators would work in 
the upgrade test context. Using a separate database would probably have 
worked too, but would have required far more "plumbing code".


[1] https://issues.apache.org/jira/browse/DERBY-5764

View raw message