db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-499) Expose BOOLEAN datatype to end users
Date Thu, 12 Jan 2006 16:54:23 GMT
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.


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

View raw message