A couple comments to the parts of the patch that affects this issue:
1) I don't think we can change DRDAConstants.DRDA_TIMESTAMP_LENGTH
from 26 to 29. This constant needs to stay at 26 to ensure that newer
servers can talk to old clients after the
DERBY-2602 changes. It is
not used by any of the meta-data calls, as far as I know, so I think
it is safe to leave this change out. You may want to run the
compatibility tests to verify that we don't break compatibility. See
for details on how to set up and run these tests.
2) We have this code in ColumnMetaData.getScale():
// We get the scale from the SQLDA as returned by DERBY, but DERBY does not return the ANSI-defined
// value of scale 6 for TIMESTAMP.
// The JDBC drivers should hardcode this info as a short/near term solution.
if (types_[column - 1] == Types.TIMESTAMP)
return sqlScale_[column - 1];
The patch changes this code to return 9 in the case of a timestamp,
which I think is fine, but I'm wondering if the special case for
timestamp could be removed now that we make the embedded driver return
9 from its getScale() method. I think the value in sqlScale_[column-1]
comes from the embedded driver, but we need to check that.
3) I see that the existing tests have been updated, and those changes
look fine to me. But do we also need new test cases to cover all the
changes listed in the functional spec? I see that the existing tests
cover these methods with the timestamp type:
But I couldn't find that we test ParameterMetaData.getPrecision() and
ParameterMetaData.getScale() with timestamp anywhere. Do you think it
would be worthwhile to add tests for those two methods?