Thanks, Kathey. I appreciate your thoroughness in reviewing this patch
and I will work on a new patch which I hope will meet your 3 conditions.
Cheers,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
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.
I understand the problem now. Embedded would show these as BIT but
client and jcc would show them as SMALLINT.
dumpRs can't know the difference without some intelligence about what
columns it is printing. odbc_metadata seems to have this, but
metadata.java does not.
A few other thoughts before I *really* leave this topic.
1) If we go to lots of masters it would seem to make sense to just
move the version testing out of metadata.java.
I think dbMetaDataJdbc30.java would be an ok place for all the
version related calls to live even though it does not run on jdk 1.3.1.
We should check the version output but don't need to check it as many
times as we do.
2) In the dodgy hack category, there is already some specific handling
by column name in dumpRs. Columns like UNSIGNED_ATTRIBUTE,
FIXED_PREC_SCALE, etc could be identified by name as boolean columns and
we could print the output of getBoolean instead of getString for those
columns.
3) In looking at this issue, I noticed that in the odbc_metadata test
the odbcComplianceTargets still have SMALLINT for values like
FIXED_PREC_SCALE instead of "BOOLEAN". I wonder if this is still right.
In the end I am A-OK with anything that
1) Still tests the version related metadata calls.
2) Allows the tests to pass on all jvms
3) Keeps a single bumpversion target for release
My two week tour of duty checking the test results is almost over, so
I will leave to someone else to do the commit for this issue. Maybe
that will be you #:)
Thanks
Kathey
