Derby
  1. Derby
  2. DERBY-4614

JDBC metadata gives incorrect lengths for timestamps

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.7.1.4, 10.8.1.2
    • Component/s: SQL
    • Labels:
      None
    • Issue & fix info:
      Newcomer
    • Bug behavior facts:
      Deviation from standard, Wrong query result

      Description

      While looking into DERBY-2602, I noticed that Derby gives the wrong lengths for various fields in the JDBC metadata for timestamps. I will attach a spec describing what I think should be done to correct this.

      1. releaseNote.html
        5 kB
        Rick Hillegas
      2. derby-4614-02-ab-compatProblem.diff
        2 kB
        Rick Hillegas
      3. d4614_hang.java
        0.5 kB
        Knut Anders Hatlen
      4. derby-4614-01-ae-warmedUp.diff
        120 kB
        Rick Hillegas
      5. derby-4614-01-ad-warmedUp.diff
        120 kB
        Rick Hillegas
      6. releaseNote.html
        5 kB
        Rick Hillegas
      7. derby-4614-01-ac-warmedUp.diff
        120 kB
        Rick Hillegas
      8. derby-4614-01-ab-warmedUp.diff
        110 kB
        Rick Hillegas
      9. derby-4614-01-aa-warmedUp.diff
        110 kB
        Rick Hillegas
      10. derby_4614-2.diff
        84 kB
        Nirmal Fernando
      11. derby-4614-1.diff
        87 kB
        Nirmal Fernando
      12. ASF.LICENSE.NOT.GRANTED--derby-4614-fs.html
        9 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Attaching functional spec for the metadata changes.

          Show
          Rick Hillegas added a comment - Attaching functional spec for the metadata changes.
          Hide
          Rick Hillegas added a comment -

          This seems like a good issue for a newcomer. This issue is a good introduction to how Derby's JDBC metadata is implemented and tested.

          Show
          Rick Hillegas added a comment - This seems like a good issue for a newcomer. This issue is a good introduction to how Derby's JDBC metadata is implemented and tested.
          Hide
          Nirmal Fernando added a comment -

          Hi Rick,

          I would like to take up this bug. I've read through the specification that you've attached.
          Can you suggest me an entry point to implement the spec? I can see that solving this bug,
          will help to solve the other linked bugs.

          Thanks.

          Show
          Nirmal Fernando added a comment - Hi Rick, I would like to take up this bug. I've read through the specification that you've attached. Can you suggest me an entry point to implement the spec? I can see that solving this bug, will help to solve the other linked bugs. Thanks.
          Hide
          Bryan Pendleton added a comment -

          Some good places to start might include:

          1) Setting up java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java
          in your debugger, so that you can have an easy way to set breakpoints in various
          metadata methods and hit them from the test.

          2) Have a look at
          java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java
          and
          java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java
          to get a feel for how some of the RSMD methods are implemented for embedded Derby

          3) Have a look at
          java/client/org/apache/derby/client/am/ColumnMetaData.java
          to get a feel for how some of the RSMD methods are implemented for client/server Derby

          Then I'd suggest having a close look through the spec and ensuring that
          the existing test programs provide reasonable test coverage for the API calls of interest.

          Show
          Bryan Pendleton added a comment - Some good places to start might include: 1) Setting up java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java in your debugger, so that you can have an easy way to set breakpoints in various metadata methods and hit them from the test. 2) Have a look at java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java and java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java to get a feel for how some of the RSMD methods are implemented for embedded Derby 3) Have a look at java/client/org/apache/derby/client/am/ColumnMetaData.java to get a feel for how some of the RSMD methods are implemented for client/server Derby Then I'd suggest having a close look through the spec and ensuring that the existing test programs provide reasonable test coverage for the API calls of interest.
          Hide
          Rick Hillegas added a comment -

          Hi Nirmal,

          In addition to Bryan's suggestions, you'll want to take a look at metadata.properties. That file contains the queries which support the DatabaseMetaData calls. Thanks.

          Show
          Rick Hillegas added a comment - Hi Nirmal, In addition to Bryan's suggestions, you'll want to take a look at metadata.properties. That file contains the queries which support the DatabaseMetaData calls. Thanks.
          Hide
          Nirmal Fernando added a comment -

          Thanks Bryan & Rick! I'll look into those.

          Show
          Nirmal Fernando added a comment - Thanks Bryan & Rick! I'll look into those.
          Hide
          Nirmal Fernando added a comment -

          Hi,

          Is there a way to find tests involved with database metadata? or the better way is, make my changes run java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1 and see the failures and change the tests?

          PS: I'm not sure whether running only java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1 will be enough. Please suggest me if not.

          Thanks.

          Show
          Nirmal Fernando added a comment - Hi, Is there a way to find tests involved with database metadata? or the better way is, make my changes run java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1 and see the failures and change the tests? PS: I'm not sure whether running only java -Xmx512m -XX:MaxPermSize=128m junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All >junitAll.out 2>&1 will be enough. Please suggest me if not. Thanks.
          Hide
          Rick Hillegas added a comment -

          Hi Nirmal,

          I don't have a comprehensive list of tests which stress the metadata calls so I would recommend running the full regression test suite. Before doing that, though, I would recommend running the following tests standalone:

          DatabaseMetaDataTest
          TestDbMetaData
          ParameterMetaDataJdbc30Test
          ResultSetMetaDataTest
          PrepStmtMetaDataTest

          In addition, I would recommend running the upgrade tests because they test the metadata in old versions of Derby and you will want to make sure that they don't break when you change the metadata in 10.7.

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Hi Nirmal, I don't have a comprehensive list of tests which stress the metadata calls so I would recommend running the full regression test suite. Before doing that, though, I would recommend running the following tests standalone: DatabaseMetaDataTest TestDbMetaData ParameterMetaDataJdbc30Test ResultSetMetaDataTest PrepStmtMetaDataTest In addition, I would recommend running the upgrade tests because they test the metadata in old versions of Derby and you will want to make sure that they don't break when you change the metadata in 10.7. Thanks, -Rick
          Hide
          Nirmal Fernando added a comment - - edited

          Hi,

          I am attaching patch #1 which is intended to implement the spec of this issue.
          Additionally this patch is addressing DERBY-4625 as well, both are co-related
          so difficult to separate.
          I ran the full regression test suite successfully!

          Thanks.

          Show
          Nirmal Fernando added a comment - - edited Hi, I am attaching patch #1 which is intended to implement the spec of this issue. Additionally this patch is addressing DERBY-4625 as well, both are co-related so difficult to separate. I ran the full regression test suite successfully! Thanks.
          Hide
          Knut Anders Hatlen added a comment -

          Hi Nirmal,

          It looks to me that this issue and DERBY-4625 are orthogonal issues that would be better addressed separately. What are the problems you have found that made them difficult to separate? To me it looks like the changes in SQLTimestamp.java and DateTimeTest.java are only related to DERBY-4625, and the changes in the other files are only related to this issue. Would that be a reasonable way to split the patch?

          Show
          Knut Anders Hatlen added a comment - Hi Nirmal, It looks to me that this issue and DERBY-4625 are orthogonal issues that would be better addressed separately. What are the problems you have found that made them difficult to separate? To me it looks like the changes in SQLTimestamp.java and DateTimeTest.java are only related to DERBY-4625 , and the changes in the other files are only related to this issue. Would that be a reasonable way to split the patch?
          Hide
          Knut Anders Hatlen added a comment -

          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
          java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/README.html
          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 6; }

          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:

          DatabaseMetaData.getTypeInfo()
          DatabaseMetaData.getProcedureColumns()
          DatabaseMetaData.getFunctionColumns()
          ResultSetMetaData.getColumnDisplaySize()
          ResultSetMetaData.getPrecision()
          ResultSetMetaData.getScale()

          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?

          Show
          Knut Anders Hatlen added a comment - 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 java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/README.html 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 6; } 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: DatabaseMetaData.getTypeInfo() DatabaseMetaData.getProcedureColumns() DatabaseMetaData.getFunctionColumns() ResultSetMetaData.getColumnDisplaySize() ResultSetMetaData.getPrecision() ResultSetMetaData.getScale() 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?
          Hide
          Knut Anders Hatlen added a comment -

          I ran the regression tests with the patch, and these three tests failed for me in derbyall:

          derbyall/derbyall.fail:lang/compressTable.sql
          derbyall/derbyall.fail:lang/specjPlans.sql
          derbyall/derbyall.fail:lang/triggerRefClause.sql

          It looks like all failures were caused by ij giving more space to timestamp columns, so we just need to update the master files.

          Show
          Knut Anders Hatlen added a comment - I ran the regression tests with the patch, and these three tests failed for me in derbyall: derbyall/derbyall.fail:lang/compressTable.sql derbyall/derbyall.fail:lang/specjPlans.sql derbyall/derbyall.fail:lang/triggerRefClause.sql It looks like all failures were caused by ij giving more space to timestamp columns, so we just need to update the master files.
          Hide
          Nirmal Fernando added a comment -

          Hi Knut,

          Regarding your first comment, when I remove those changes earlier I got some test failures in DateTimeTest. But now I can't reproduce them. So I'll provide separate patches.
          Thanks for pointing that out.

          Show
          Nirmal Fernando added a comment - Hi Knut, Regarding your first comment, when I remove those changes earlier I got some test failures in DateTimeTest. But now I can't reproduce them. So I'll provide separate patches. Thanks for pointing that out.
          Hide
          Kathey Marsden added a comment -

          Hi Nirmal,

          I haven't had a chance to look at the patch, but i know earlier you asked about specific tests for database metadata. Traditionally one area of concern regrarding these queries has been upgrade because they are stored in the database. Hopefully we have that worked out with the fix for DERBY-1107,

          I believe the upgrade tests test test metadata make sure that everything behaves properly. But it would be interesting to do some ad hoc testing around soft upgrade, particularly with maintenance versions around your changes.

          Thanks

          Kathey

          Show
          Kathey Marsden added a comment - Hi Nirmal, I haven't had a chance to look at the patch, but i know earlier you asked about specific tests for database metadata. Traditionally one area of concern regrarding these queries has been upgrade because they are stored in the database. Hopefully we have that worked out with the fix for DERBY-1107 , I believe the upgrade tests test test metadata make sure that everything behaves properly. But it would be interesting to do some ad hoc testing around soft upgrade, particularly with maintenance versions around your changes. Thanks Kathey
          Hide
          Nirmal Fernando added a comment -

          Hi Knut,

          Regarding your second comment,

          1) I found that in java/engine/org/apache/derby/iapi/types/TypeId.java we use "public static final int TIMESTAMP_MAXWIDTH = DRDAConstants.DRDA_TIMESTAMP_LENGTH; // yyyy-mm-dd hh:mm:ss.fffffffff".

          2) I'll look into it.

          3) I'll add some tests.

          Regarding your third comment,
          Sorry about that I did not run derbyall previously, I'll update those tests soon, thanks for running tests Knut!

          Thanks again for quick reviews!

          Show
          Nirmal Fernando added a comment - Hi Knut, Regarding your second comment, 1) I found that in java/engine/org/apache/derby/iapi/types/TypeId.java we use "public static final int TIMESTAMP_MAXWIDTH = DRDAConstants.DRDA_TIMESTAMP_LENGTH; // yyyy-mm-dd hh:mm:ss.fffffffff". 2) I'll look into it. 3) I'll add some tests. Regarding your third comment, Sorry about that I did not run derbyall previously, I'll update those tests soon, thanks for running tests Knut! Thanks again for quick reviews!
          Hide
          Nirmal Fernando added a comment -

          Hi,

          I've separated the derby-4625 issue related changes from this issue, in patch #2.
          But I couldn't find any time to look at Knut's 2) & 3) points in his one before last comment.
          I've unassigned my self from this issue since I've to concentrate on my final year research project.

          Things to be done:
          1) Run regression tests on new patch
          2) Consider Knut's above mentioned 2nd & 3rd points

          Thanks for all the help provided on this issue!

          Show
          Nirmal Fernando added a comment - Hi, I've separated the derby-4625 issue related changes from this issue, in patch #2. But I couldn't find any time to look at Knut's 2) & 3) points in his one before last comment. I've unassigned my self from this issue since I've to concentrate on my final year research project. Things to be done: 1) Run regression tests on new patch 2) Consider Knut's above mentioned 2nd & 3rd points Thanks for all the help provided on this issue!
          Hide
          Knut Anders Hatlen added a comment -

          From the comments it sounds like the patch is not quite ready yet, so I'm removing the Patch Available flag.

          Show
          Knut Anders Hatlen added a comment - From the comments it sounds like the patch is not quite ready yet, so I'm removing the Patch Available flag.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-4614-01-aa-warmedUp.diff. This warms up Nirmal's second patch, updating a couple more test canons for ij tests whose output changed because the width of timestamp columns has grown.

          Touches the following files:

          M java/engine/org/apache/derby/impl/jdbc/metadata.properties
          M java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java
          M java/engine/org/apache/derby/iapi/types/TypeId.java
          M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/TableFunctionTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CoalesceTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/PrepStmtMetaDataTest.java
          M java/testing/org/apache/derbyTesting/functionTests/master/cast.out
          M java/testing/org/apache/derbyTesting/functionTests/master/aggbuiltin.out
          M java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out
          M java/testing/org/apache/derbyTesting/functionTests/master/nonreserved.out
          M java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out
          M java/testing/org/apache/derbyTesting/functionTests/master/orderby.out
          M java/testing/org/apache/derbyTesting/functionTests/master/specjPlans.out
          M java/testing/org/apache/derbyTesting/functionTests/master/insert.out
          M java/testing/org/apache/derbyTesting/functionTests/master/triggerRefClause.out
          M java/client/org/apache/derby/client/am/ColumnMetaData.java

          Show
          Rick Hillegas added a comment - Attaching derby-4614-01-aa-warmedUp.diff. This warms up Nirmal's second patch, updating a couple more test canons for ij tests whose output changed because the width of timestamp columns has grown. Touches the following files: M java/engine/org/apache/derby/impl/jdbc/metadata.properties M java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java M java/engine/org/apache/derby/iapi/types/TypeId.java M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/TableFunctionTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CoalesceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/PrepStmtMetaDataTest.java M java/testing/org/apache/derbyTesting/functionTests/master/cast.out M java/testing/org/apache/derbyTesting/functionTests/master/aggbuiltin.out M java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out M java/testing/org/apache/derbyTesting/functionTests/master/nonreserved.out M java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out M java/testing/org/apache/derbyTesting/functionTests/master/orderby.out M java/testing/org/apache/derbyTesting/functionTests/master/specjPlans.out M java/testing/org/apache/derbyTesting/functionTests/master/insert.out M java/testing/org/apache/derbyTesting/functionTests/master/triggerRefClause.out M java/client/org/apache/derby/client/am/ColumnMetaData.java
          Hide
          Rick Hillegas added a comment -

          Attaching derby-4614-01-ab-warmedUp.diff. This removes the special case in ColumnMetaData.getScale() per Knut's second recommendation on 2010-09-02. Tests ran cleanly for me.

          Touches the same files as the previous version of the warmed-up patch.

          Show
          Rick Hillegas added a comment - Attaching derby-4614-01-ab-warmedUp.diff. This removes the special case in ColumnMetaData.getScale() per Knut's second recommendation on 2010-09-02. Tests ran cleanly for me. Touches the same files as the previous version of the warmed-up patch.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-4614-01-ac-warmedUp.diff. This patch adds more tests, addressing Knut's third concern. I am running regression tests now.

          Touches the following files:

          M java/engine/org/apache/derby/impl/jdbc/metadata.properties
          M java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java
          M java/engine/org/apache/derby/iapi/types/TypeId.java
          M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/TableFunctionTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CoalesceTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMetaDataJdbc30Test.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/PrepStmtMetaDataTest.java
          M java/testing/org/apache/derbyTesting/functionTests/master/cast.out
          M java/testing/org/apache/derbyTesting/functionTests/master/aggbuiltin.out
          M java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out
          M java/testing/org/apache/derbyTesting/functionTests/master/nonreserved.out
          M java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out
          M java/testing/org/apache/derbyTesting/functionTests/master/orderby.out
          M java/testing/org/apache/derbyTesting/functionTests/master/specjPlans.out
          M java/testing/org/apache/derbyTesting/functionTests/master/insert.out
          M java/testing/org/apache/derbyTesting/functionTests/master/triggerRefClause.out
          M java/client/org/apache/derby/client/am/ColumnMetaData.java

          Show
          Rick Hillegas added a comment - Attaching derby-4614-01-ac-warmedUp.diff. This patch adds more tests, addressing Knut's third concern. I am running regression tests now. Touches the following files: M java/engine/org/apache/derby/impl/jdbc/metadata.properties M java/engine/org/apache/derby/iapi/types/DataTypeUtilities.java M java/engine/org/apache/derby/iapi/types/TypeId.java M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/TableFunctionTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CoalesceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ResultSetMiscTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMetaDataJdbc30Test.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/PrepStmtMetaDataTest.java M java/testing/org/apache/derbyTesting/functionTests/master/cast.out M java/testing/org/apache/derbyTesting/functionTests/master/aggbuiltin.out M java/testing/org/apache/derbyTesting/functionTests/master/implicitConversions.out M java/testing/org/apache/derbyTesting/functionTests/master/nonreserved.out M java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out M java/testing/org/apache/derbyTesting/functionTests/master/orderby.out M java/testing/org/apache/derbyTesting/functionTests/master/specjPlans.out M java/testing/org/apache/derbyTesting/functionTests/master/insert.out M java/testing/org/apache/derbyTesting/functionTests/master/triggerRefClause.out M java/client/org/apache/derby/client/am/ColumnMetaData.java
          Hide
          Rick Hillegas added a comment -

          Attaching a release note for this issue.

          Show
          Rick Hillegas added a comment - Attaching a release note for this issue.
          Hide
          Rick Hillegas added a comment -

          Attaching a new rev of the patch, derby-4614-01-ad-warmedUp.diff. DatabaseMetaDataTest failed on the last rev when run on Java 5. The new rev fixes the reflection performed by that test when it invokes the getFunctionColumns() method. Now DatabaseMetaDataTest runs cleanly on Java 5. Re-running regression tests now.

          Touches the same files as the previous patch.

          Show
          Rick Hillegas added a comment - Attaching a new rev of the patch, derby-4614-01-ad-warmedUp.diff. DatabaseMetaDataTest failed on the last rev when run on Java 5. The new rev fixes the reflection performed by that test when it invokes the getFunctionColumns() method. Now DatabaseMetaDataTest runs cleanly on Java 5. Re-running regression tests now. Touches the same files as the previous patch.
          Hide
          Rick Hillegas added a comment -

          Tests passed cleanly for me on the latest patch.

          Show
          Rick Hillegas added a comment - Tests passed cleanly for me on the latest patch.
          Hide
          Knut Anders Hatlen added a comment -

          Hi Rick,

          Some minor comments to the patch:

          • The @param tags in the javadoc for ParameterMetaDataJdbc30Test.dummyString() don't match the actual parameters.
          • The assertResults() method in DatabaseMetaDataTest appears to be reinventing JDBC.assertFullResultSet().
          • The javadoc for DatabaseMetaDataTest stops in the middle of a sentence (ends with a comma), and its @throws tag misspells SQLException.

          Apart from that, the patch looks good to me.

          Show
          Knut Anders Hatlen added a comment - Hi Rick, Some minor comments to the patch: The @param tags in the javadoc for ParameterMetaDataJdbc30Test.dummyString() don't match the actual parameters. The assertResults() method in DatabaseMetaDataTest appears to be reinventing JDBC.assertFullResultSet(). The javadoc for DatabaseMetaDataTest stops in the middle of a sentence (ends with a comma), and its @throws tag misspells SQLException. Apart from that, the patch looks good to me.
          Hide
          Rick Hillegas added a comment -

          Thanks for the review, Knut. Attaching derby-4614-01-ae-warmedUp.diff, which addresses most of your concerns. I did not use JDBC.assertFullResultSet because I needed trickier comparison logic to handle system-generated names. Committed at subversion revision 1042675.

          Show
          Rick Hillegas added a comment - Thanks for the review, Knut. Attaching derby-4614-01-ae-warmedUp.diff, which addresses most of your concerns. I did not use JDBC.assertFullResultSet because I needed trickier comparison logic to handle system-generated names. Committed at subversion revision 1042675.
          Hide
          Knut Anders Hatlen added a comment -

          JDBC.assertFullResultSet() does have logic to handle system-generated names. Take a look at TableFunctionTest for an example.

          Show
          Knut Anders Hatlen added a comment - JDBC.assertFullResultSet() does have logic to handle system-generated names. Take a look at TableFunctionTest for an example.
          Hide
          Rick Hillegas added a comment -

          Ported 1042675 from trunk to 10.7 branch at subversion revision 1042682.

          Show
          Rick Hillegas added a comment - Ported 1042675 from trunk to 10.7 branch at subversion revision 1042682.
          Hide
          Rick Hillegas added a comment -

          Thanks for that information, Knut. I am declaring victory on this issue. Cheers.

          Show
          Rick Hillegas added a comment - Thanks for that information, Knut. I am declaring victory on this issue. Cheers.
          Hide
          Knut Anders Hatlen added a comment -

          I'm reopening this issue since the compatibility tests have not been able to complete in the tinderbox or in the nightly tests after the patch was checked in. They seem to hang when testing old clients against servers running trunk.

          Show
          Knut Anders Hatlen added a comment - I'm reopening this issue since the compatibility tests have not been able to complete in the tinderbox or in the nightly tests after the patch was checked in. They seem to hang when testing old clients against servers running trunk.
          Hide
          Knut Anders Hatlen added a comment -

          The attached Java program (d4614_hang.java) reproduces the hang outside of the compatibility tests. Start a server running trunk and run the program with the 10.5.3.0 (or earlier) client driver, and you'll see the hang. It doesn't hang with a 10.6 client.

          Show
          Knut Anders Hatlen added a comment - The attached Java program (d4614_hang.java) reproduces the hang outside of the compatibility tests. Start a server running trunk and run the program with the 10.5.3.0 (or earlier) client driver, and you'll see the hang. It doesn't hang with a 10.6 client.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-4614-02-ab-compatProblem.diff. This fixes the problem case which Knut found. I will run regression tests.

          This patch makes the trunk client and server use 26 character timestamps if the other end of the connection does not expect nanosecond precision.

          I have tested Knut's problem case in the following scenarios:

          1) Client = trunk; server = trunk

          2) Client = trunk; server = 10.5

          3) Client = trunk; server = 10.6

          4) Client = 10.6; server = trunk

          5) Client = 10.5; server = trunk

          I have successfully run the compatibility tests on Java 6 using clients and servers at the following rev levels:

          trunk
          10.4.2.1
          10.6.1.0

          Touches the following files:

          -------------

          M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java

          Introduced a constant to represent the old 26 character timestamp length.

          -------------

          M java/drda/org/apache/derby/impl/drda/AppRequester.java
          M java/client/org/apache/derby/client/am/DateTime.java

          Use the old length if the other side of the connection expects it.

          Show
          Rick Hillegas added a comment - Attaching derby-4614-02-ab-compatProblem.diff. This fixes the problem case which Knut found. I will run regression tests. This patch makes the trunk client and server use 26 character timestamps if the other end of the connection does not expect nanosecond precision. I have tested Knut's problem case in the following scenarios: 1) Client = trunk; server = trunk 2) Client = trunk; server = 10.5 3) Client = trunk; server = 10.6 4) Client = 10.6; server = trunk 5) Client = 10.5; server = trunk I have successfully run the compatibility tests on Java 6 using clients and servers at the following rev levels: trunk 10.4.2.1 10.6.1.0 Touches the following files: ------------- M java/engine/org/apache/derby/iapi/reference/DRDAConstants.java Introduced a constant to represent the old 26 character timestamp length. ------------- M java/drda/org/apache/derby/impl/drda/AppRequester.java M java/client/org/apache/derby/client/am/DateTime.java Use the old length if the other side of the connection expects it.
          Hide
          Rick Hillegas added a comment -

          Tests ran cleanly for me. Committed derby-4614-02-ab-compatProblem.diff at subversion revision 1049180.

          Show
          Rick Hillegas added a comment - Tests ran cleanly for me. Committed derby-4614-02-ab-compatProblem.diff at subversion revision 1049180.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Rick! The compatibility tests completed successfully in the latest run of the tinderbox, so the fix seems to have done the trick.

          Show
          Knut Anders Hatlen added a comment - Thanks, Rick! The compatibility tests completed successfully in the latest run of the tinderbox, so the fix seems to have done the trick.
          Hide
          Rick Hillegas added a comment -

          At the risk of jinxing this re-opened bug, I am going to re-close it.

          Show
          Rick Hillegas added a comment - At the risk of jinxing this re-opened bug, I am going to re-close it.
          Hide
          Knut Anders Hatlen added a comment -

          The original fix was backported to 10.7, so we probably need to backport the fix for the compatibility issue too.

          Show
          Knut Anders Hatlen added a comment - The original fix was backported to 10.7, so we probably need to backport the fix for the compatibility issue too.
          Hide
          Rick Hillegas added a comment -

          Good point, Knut. Ported 1049180 from trunk to 10.7 branch at subversion revision 1049569.

          Show
          Rick Hillegas added a comment - Good point, Knut. Ported 1049180 from trunk to 10.7 branch at subversion revision 1049569.
          Hide
          Rick Hillegas added a comment -

          Re-opening this issue, hoping that this will let me attach a revised release note.

          Show
          Rick Hillegas added a comment - Re-opening this issue, hoping that this will let me attach a revised release note.
          Hide
          Rick Hillegas added a comment -

          Adjusted the release note.

          Show
          Rick Hillegas added a comment - Adjusted the release note.

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development