Derby
  1. Derby
  2. DERBY-3797

Convert jdbcapi/metadataMultiConn to JUnit.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.5.1.1
    • Fix Version/s: 10.5.1.1
    • Component/s: Test
    • Labels:
      None
    1. Derby-3797_2.diff
      22 kB
      Erlend Birkenes

      Activity

      Hide
      Erlend Birkenes added a comment -

      This is a pretty bad test if I understand it correctly.

      Take the method getTypeInfo for example. All this does is test that the result set has at least 15 columns. (It has 18..)

      What exactly is it this is supposed to test?

      Show
      Erlend Birkenes added a comment - This is a pretty bad test if I understand it correctly. Take the method getTypeInfo for example. All this does is test that the result set has at least 15 columns. (It has 18..) What exactly is it this is supposed to test?
      Hide
      Erlend Birkenes added a comment -

      If I do this:

      int[] expectedTypes =

      {Types.VARCHAR, Types.INTEGER, Types.INTEGER, Types.VARCHAR, Types.VARCHAR, Types.VARCHAR, Types.SMALLINT, Types.BOOLEAN, Types.SMALLINT, Types.BOOLEAN, Types.BOOLEAN, Types.BOOLEAN, Types.VARCHAR, Types.SMALLINT, Types.SMALLINT, Types.INTEGER, Types.INTEGER, Types.INTEGER}

      ;

      JDBC.assertColumnTypes(rs, expectedTypes);

      is that what the last test was trying to do?

      Show
      Erlend Birkenes added a comment - If I do this: int[] expectedTypes = {Types.VARCHAR, Types.INTEGER, Types.INTEGER, Types.VARCHAR, Types.VARCHAR, Types.VARCHAR, Types.SMALLINT, Types.BOOLEAN, Types.SMALLINT, Types.BOOLEAN, Types.BOOLEAN, Types.BOOLEAN, Types.VARCHAR, Types.SMALLINT, Types.SMALLINT, Types.INTEGER, Types.INTEGER, Types.INTEGER} ; JDBC.assertColumnTypes(rs, expectedTypes); is that what the last test was trying to do?
      Hide
      Kathey Marsden added a comment -

      The test was originally added in a bug fix that metadata calls were taking too long a time when executed with mutiple connections. This was the checkin comment:

      if we do need to create SPS during metadata calls (eg., in SPS dynamic
      mode), we'd better do it in nested transaction, to be consistent with
      our SPS recompile, although this has the disadvantage of the possibility
      of blocking in child transaction with parent, especially in "serializable"'

      So I think the general intention of the test was to test metadata calls when executed with multiple connections, and perhaps the author was not thorough in checking the actual results. Anything you add to improve that would be welcome.

      Show
      Kathey Marsden added a comment - The test was originally added in a bug fix that metadata calls were taking too long a time when executed with mutiple connections. This was the checkin comment: if we do need to create SPS during metadata calls (eg., in SPS dynamic mode), we'd better do it in nested transaction, to be consistent with our SPS recompile, although this has the disadvantage of the possibility of blocking in child transaction with parent, especially in "serializable"' So I think the general intention of the test was to test metadata calls when executed with multiple connections, and perhaps the author was not thorough in checking the actual results. Anything you add to improve that would be welcome.
      Hide
      Erlend Birkenes added a comment -

      Please review and commit if everything is ok.

      I hope I have understood the old test correctly and that this really does the same thing.
      I ended up with just using assertDrainResults since the point was just to read the metadata from several different connections as I understand it.
      So I just use assertDrainResults to read through the data and close the resultset and thets pretty much what the old test did too.

      I've added it to jdbcapi/_Suite and removed the old test.

      I've run the _Suite, but not All

      -Erlend

      Show
      Erlend Birkenes added a comment - Please review and commit if everything is ok. I hope I have understood the old test correctly and that this really does the same thing. I ended up with just using assertDrainResults since the point was just to read the metadata from several different connections as I understand it. So I just use assertDrainResults to read through the data and close the resultset and thets pretty much what the old test did too. I've added it to jdbcapi/_Suite and removed the old test. I've run the _Suite, but not All -Erlend
      Hide
      Myrna van Lunteren added a comment -

      The new test looks ok to me. I committed patch Derby-3797_2.diff with revision 685553.

      Show
      Myrna van Lunteren added a comment - The new test looks ok to me. I committed patch Derby-3797_2.diff with revision 685553.

        People

        • Assignee:
          Erlend Birkenes
          Reporter:
          Erlend Birkenes
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development