Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-3797

Convert jdbcapi/metadataMultiConn to JUnit.

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: 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
      myrna 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 Myrna van Lunteren added a comment - The new test looks ok to me. I committed patch Derby-3797_2.diff with revision 685553.
      Hide
      ebirkenes 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
      ebirkenes 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
      kmarsden 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
      kmarsden 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
      ebirkenes 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
      ebirkenes 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
      ebirkenes 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
      ebirkenes 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?

        People

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

          Dates

          • Created:
            Updated:
            Resolved:

            Development