In my local codeline I added a new upgrade fixture to
upgradeTests/Changes10_4.java that creates a primary key and several
foreign keys. After doing so I noticed that a handful of the fixtures
in jdbcapi/DatabaseMetaDataTest, when run as part of
upgradeTests/_Suite.java, started failing.
From what I can tell there are a couple of test cases--esp. for ODBC
testing--which execute DatabaseMetaData procedures that are meant to
return "all (non-system) keys in the database". Since the ChangesXX_y
tests are interspersed with DatabaseMetaDataTests for each phase, and
since my new fixture in Changes10_4.java creates several new keys, the
metadata test cases which check for "all keys in the database" now have
more rows than previously expected, and thus fail. But if I change the
DatabaseMetaData tests to account for the additional keys, they will
fail when run standalone because those keys won't exist outside of the
upgrade suite.
I couldn't find any obvious "quick fixes" for this, so I made some
changes locally to separate the database metadata upgrade tests out from
the ChangesXX_y upgrade tests, so that the former are not affected by
the latter. I.e. with my changes upgradeTests/_Suite will first run a
suite that tests the 5 phases of upgrade with the various ChangesXX_y
fixtures, and then when that's done, it'll start a second suite that
repeats the 5 phases with the DatabaseMetaData tests. This seems to
have worked for me locally...
But is that really necessary, or is there a known (cleaner) way to deal
with this kind of thing?
For what it's worth, I did a quick grep for "foreign" and "primary" in
the various ChangesXX_y.java files and found no declarations of primary
nor foreign keys. So I'm guessing this particular behavior is simply
not an issue with the current set of upgrade tests...but I could of
course be mistaken...
Army
