Hi Kathey,
I'd welcome your suggestions about how to recode the test to behave as
you describe. It seems difficult to me because the code in question
doesn't know that the columns are supposed to be BOOLEAN. The code in
question is inspecting ResultSetMetaData, which returns different type
information depending on your vm. On jdk1.3 (JDBC 3), you can't tell
SMALLINT from BOOLEAN just by inspecting ResultSetMetaData. To achieve
what you want, I think this test needs to be substantially rewritten.
It's a very brittle test, as seen by the fact that it already gives rise
to so many platform-specific canons. I do think it needs to be rewritten
but that seems to me is pulling on too big a ball of yarn. I need a
practical way forward.
Thanks,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
I don't want to pull on a big ball of yarn, either. Do you think the
following changes will be adequate?
1) Remove the hard-coded release-specific variables from the metadata
test.
2) Go back to printing release variables in the canons.
3) Update the bumplastdigit target to include the new canons.
That still creates lots of scenarios where people are not updating the
version but do want to update the master for this test. In those cases
they would have to update jdk131 masters as well.
I had thought ideally the solution would be something like the test
using getBoolean to access boolean values and printing an assertion if
they are not the value expected instead of printing the output of
getString. I think we would tell a user using getString on the boolean
columns in jdk 1.3.1 to use getBoolean, so it would be good if our test
used the same practice..
For syscat, multiple masters might be ok as it is not affected by the
version. An alternative might be to use a case statement in the queries
to normalize the output.
Kathey
