Derby
  1. Derby
  2. DERBY-4932

Move the StringColumnVTI to the public api

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.8.1.2
    • Component/s: Javadoc, SQL, Tools
    • Labels:
      None

      Description

      I have found StringColumnVTI to be a very useful class for removing the drudgery of writing a table function. I would like to move it to move it into the package with the other public vti machinery and then expose it as part of Derby's public api.

      1. derby-4932-06-aa-packageProtection.diff
        0.5 kB
        Rick Hillegas
      2. derby-4932-05-ab-addJDBC4.0versions.diff
        53 kB
        Rick Hillegas
      3. derby-4932-05-aa-addJDBC4.0versions.diff
        67 kB
        Rick Hillegas
      4. derby-4932-04-aa-retireDemoVersion.diff
        22 kB
        Rick Hillegas
      5. derby-4932-03-aa-useInMemoryDBinDemos.diff
        2 kB
        Rick Hillegas
      6. derby-4932-02-ab-moveStringColumnVTI.diff
        48 kB
        Rick Hillegas
      7. derby-4932-02-aa-moveStringColumnVTI.diff
        48 kB
        Rick Hillegas
      8. derby-4932-01-aa-exposeVTITemplate.diff
        2 kB
        Rick Hillegas

        Activity

        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-01-aa-exposeVTITemplate.diff. This patch exposes the VTITemplate class as the first step toward publishing the StringColumnVTI. Committed at subversion revision 1042768.

        10.4 was the first release to expose table functions. It was also the first release which exposed classes in the org.apache.derby.vti package. The first classes from that package which were exposed were VTICosting and VTIEnvironment. In 10.6 we also exposed the classes needed to implement restricted table functions: RestrictedVTI and the Restriction classes.

        I think that we should have exposed VTITemplate when we introduced user-written table functions. That class was described in the Cloudscape 3.5 Developer's Guide.

        A future enhancement would be to write a more extensive tutorial on how to write table functions.

        Touches the following files:

        ----------

        M java/engine/org/apache/derby/vti/VTITemplate.java

        Minor tweaks to clarify that VTITemplate is useful for writing new-style table functions as well as old-style VTIs.

        ----------

        M tools/javadoc/publishedapi.ant

        Added VTITemplate to the list of public Derby classes.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-01-aa-exposeVTITemplate.diff. This patch exposes the VTITemplate class as the first step toward publishing the StringColumnVTI. Committed at subversion revision 1042768. 10.4 was the first release to expose table functions. It was also the first release which exposed classes in the org.apache.derby.vti package. The first classes from that package which were exposed were VTICosting and VTIEnvironment. In 10.6 we also exposed the classes needed to implement restricted table functions: RestrictedVTI and the Restriction classes. I think that we should have exposed VTITemplate when we introduced user-written table functions. That class was described in the Cloudscape 3.5 Developer's Guide. A future enhancement would be to write a more extensive tutorial on how to write table functions. Touches the following files: ---------- M java/engine/org/apache/derby/vti/VTITemplate.java Minor tweaks to clarify that VTITemplate is useful for writing new-style table functions as well as old-style VTIs. ---------- M tools/javadoc/publishedapi.ant Added VTITemplate to the list of public Derby classes.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-02-aa-moveStringColumnVTI.diff. This patch moves StringColumnVTI from its test package to the public api. I am running regression tests now.

        Touches the following files:

        ----------

        A java/engine/org/apache/derby/vti/StringColumnVTI.java
        D java/testing/org/apache/derbyTesting/functionTests/tests/lang/StringColumnVTI.java

        Moves the class. Makes StringColumnVTI use the Harmony LOBs rather than its own, cruder implementations. Also stubs out the getMetaData() method which is not needed for table functions.

        ----------

        M java/engine/org/apache/derby/vti/build.xml

        Wires StringColumnVTI into the 1.4 build of this package.

        ----------

        M tools/javadoc/publishedapi.ant

        Adds StringColumnVTI to the public api.

        ----------

        M java/engine/org/apache/derby/iapi/types/HarmonySerialBlob.java
        M java/engine/org/apache/derby/iapi/types/HarmonySerialClob.java

        Corrects the header comments for these classes.

        ----------

        M java/testing/org/apache/derbyTesting/functionTests/tests/lang/BooleanValuesTest.java
        M java/testing/org/apache/derbyTesting/functionTests/tests/lang/StringArrayVTI.java
        M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiSignatures.java
        M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMappingTest.java

        Various changes to reflect the fact that StringColumnVTI moved and its crude LOB implementations have been removed.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-02-aa-moveStringColumnVTI.diff. This patch moves StringColumnVTI from its test package to the public api. I am running regression tests now. Touches the following files: ---------- A java/engine/org/apache/derby/vti/StringColumnVTI.java D java/testing/org/apache/derbyTesting/functionTests/tests/lang/StringColumnVTI.java Moves the class. Makes StringColumnVTI use the Harmony LOBs rather than its own, cruder implementations. Also stubs out the getMetaData() method which is not needed for table functions. ---------- M java/engine/org/apache/derby/vti/build.xml Wires StringColumnVTI into the 1.4 build of this package. ---------- M tools/javadoc/publishedapi.ant Adds StringColumnVTI to the public api. ---------- M java/engine/org/apache/derby/iapi/types/HarmonySerialBlob.java M java/engine/org/apache/derby/iapi/types/HarmonySerialClob.java Corrects the header comments for these classes. ---------- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/BooleanValuesTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/StringArrayVTI.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiSignatures.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ParameterMappingTest.java Various changes to reflect the fact that StringColumnVTI moved and its crude LOB implementations have been removed.
        Hide
        Dag H. Wanvik added a comment -

        > I think that we should have exposed VTITemplate when we introduced
        > user-written table functions. That class was described in the
        > Cloudscape 3.5 Developer's Guide. A future enhancement would be to
        > write a more extensive tutorial on how to write table functions.

        Both seem good. +1

        Show
        Dag H. Wanvik added a comment - > I think that we should have exposed VTITemplate when we introduced > user-written table functions. That class was described in the > Cloudscape 3.5 Developer's Guide. A future enhancement would be to > write a more extensive tutorial on how to write table functions. Both seem good. +1
        Hide
        Knut Anders Hatlen added a comment -

        Sounds like a useful improvement to me too.

        We also have a copy of StringColumnVTI.java in the demo tree. Should we update the demos to use the public class instead?

        Show
        Knut Anders Hatlen added a comment - Sounds like a useful improvement to me too. We also have a copy of StringColumnVTI.java in the demo tree. Should we update the demos to use the public class instead?
        Hide
        Rick Hillegas added a comment -

        Thanks for your comments, Dag and Knut. I agree that it would be good to use the public version in the demo and retire the version there.

        Show
        Rick Hillegas added a comment - Thanks for your comments, Dag and Knut. I agree that it would be good to use the public version in the demo and retire the version there.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-02-ab-moveStringColumnVTI.diff. The first rev of this patch passed derbyall. However, the JUnit tests bombed at the outset on an InvocationTargetException raised because StringColumnVTI wasn't included in the engine jar. This second rev of the patch adds StringColumnVTI to the engine jar. I am re-running the JUnit tests.

        This patch touches the following additional file:

        -----------

        M tools/jar/extraDBMSclasses.properties

        Adds StringColumnVTI to the list of extra classes which need to be included in the engine jar.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-02-ab-moveStringColumnVTI.diff. The first rev of this patch passed derbyall. However, the JUnit tests bombed at the outset on an InvocationTargetException raised because StringColumnVTI wasn't included in the engine jar. This second rev of the patch adds StringColumnVTI to the engine jar. I am re-running the JUnit tests. This patch touches the following additional file: ----------- M tools/jar/extraDBMSclasses.properties Adds StringColumnVTI to the list of extra classes which need to be included in the engine jar.
        Hide
        Rick Hillegas added a comment -

        JUnit tests ran cleanly for me. Committed derby-4932-02-ab-moveStringColumnVTI.diff at subversion revision 1043122.

        Show
        Rick Hillegas added a comment - JUnit tests ran cleanly for me. Committed derby-4932-02-ab-moveStringColumnVTI.diff at subversion revision 1043122.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-03-aa-useInMemoryDBinDemos.diff. Before changing the demo vtis to use the new StringColumnVTI, I thought it would be good to cleanup the existing demo scripts. This patch makes the demo scripts use an in-memory database. Committed at subversion revision 1043130.

        Touches the following files:

        M java/demo/vtis/sql/demoFileVtis.sql
        M java/demo/vtis/sql/demoForeignDbmsVtis.sql

        Show
        Rick Hillegas added a comment - Attaching derby-4932-03-aa-useInMemoryDBinDemos.diff. Before changing the demo vtis to use the new StringColumnVTI, I thought it would be good to cleanup the existing demo scripts. This patch makes the demo scripts use an in-memory database. Committed at subversion revision 1043130. Touches the following files: M java/demo/vtis/sql/demoFileVtis.sql M java/demo/vtis/sql/demoForeignDbmsVtis.sql
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-04-aa-retireDemoVersion.diff. This patch removes the demo version of StringColumnVTI. I will run the regression tests.

        Touches the following files:

        ----------

        M java/engine/org/apache/derby/vti/StringColumnVTI.java

        Add some accessors to expose column name information which some subclasses need.

        ----------

        D java/demo/vtis/java/org/apache/derbyDemo/vtis/core/StringColumnVTI.java

        Retire this class.

        ----------

        M java/demo/vtis/java/org/apache/derbyDemo/vtis/core/XmlVTI.java
        M java/demo/vtis/java/org/apache/derbyDemo/vtis/example/DerbyJiraReportVTI.java

        Use new accessors to look up column names.

        ----------

        M java/demo/vtis/java/org/apache/derbyDemo/vtis/core/FlatFileVTI.java

        Extend public version of StringColumnVTI.

        ----------

        M java/demo/vtis/java/org/apache/derbyDemo/vtis/example/ApacheServerLogVTI.java

        Eliminate the need for a setWasNull() method.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-04-aa-retireDemoVersion.diff. This patch removes the demo version of StringColumnVTI. I will run the regression tests. Touches the following files: ---------- M java/engine/org/apache/derby/vti/StringColumnVTI.java Add some accessors to expose column name information which some subclasses need. ---------- D java/demo/vtis/java/org/apache/derbyDemo/vtis/core/StringColumnVTI.java Retire this class. ---------- M java/demo/vtis/java/org/apache/derbyDemo/vtis/core/XmlVTI.java M java/demo/vtis/java/org/apache/derbyDemo/vtis/example/DerbyJiraReportVTI.java Use new accessors to look up column names. ---------- M java/demo/vtis/java/org/apache/derbyDemo/vtis/core/FlatFileVTI.java Extend public version of StringColumnVTI. ---------- M java/demo/vtis/java/org/apache/derbyDemo/vtis/example/ApacheServerLogVTI.java Eliminate the need for a setWasNull() method.
        Hide
        Rick Hillegas added a comment -

        Tests passed cleanly for me except for the ping test. Committed derby-4932-04-aa-retireDemoVersion.diff at subversion revision 1043245.

        Show
        Rick Hillegas added a comment - Tests passed cleanly for me except for the ping test. Committed derby-4932-04-aa-retireDemoVersion.diff at subversion revision 1043245.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-05-aa-addJDBC4.0versions.diff. This patch adds JDBC 4.0 versions of VTITemplate and StringColumnVTI. I will run regression tests.

        The VTITemplate and StringColumnVTI classes implement the JDBC 3.0 version of ResultSet. If you extend these classes, adding just the methods described in their header contract, the resulting classes will not compile on Java 6 because they lack stubs for the new methods introduced by JDBC 4.0. This patch introduces VTITemplate40 and StringColumnVTI40. The new classes provide stubs for the methods introduced by JDBC 4.0.

        In addition, now VTITemplate and StringColumnVTI appear only in the JDBC3 version of Derby's public api. The JDBC4 version contains the *40 equivalents.

        While I was in there, re-wrote VTITemplate so that the stubs throw a more informative notImplemented() exception.

        Note that after this patch is committed, we should hold-off closing this issue. We will want to add a couple methods to the new classes in order to satisfy the JDBC 4.1 (Java 7) contract for ResultSet.

        Touches the following files:

        ----------

        A java/engine/org/apache/derby/vti/VTITemplate40.java
        A java/engine/org/apache/derby/vti/StringColumnVTI40.java

        These classes extend their JDBC 3.0 counterparts but add the new methods introduced by JDBC 4.0.

        ----------

        M java/engine/org/apache/derby/vti/StringColumnVTI.java
        M java/engine/org/apache/derby/vti/VTITemplate.java

        Changed the header comments to indicate that these are the JDBC 3.0 versions. Also rewrote VTITemplate to throw more informative exceptions.

        ----------

        M java/engine/org/apache/derby/vti/build.xml

        Used the appropriate compiler level and libraries for the different JDBC levels.

        ----------

        M tools/javadoc/publishedapi_jdbc3.ant
        M tools/javadoc/publishedapi_jdbc4.ant
        M tools/javadoc/publishedapi.ant

        Made the appropriate classes appear in the JDBC3 and JDBC4 public api.

        ----------

        M tools/jar/extraDBMSclasses.properties

        Added the new *40 classes to the engine jar file.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-05-aa-addJDBC4.0versions.diff. This patch adds JDBC 4.0 versions of VTITemplate and StringColumnVTI. I will run regression tests. The VTITemplate and StringColumnVTI classes implement the JDBC 3.0 version of ResultSet. If you extend these classes, adding just the methods described in their header contract, the resulting classes will not compile on Java 6 because they lack stubs for the new methods introduced by JDBC 4.0. This patch introduces VTITemplate40 and StringColumnVTI40. The new classes provide stubs for the methods introduced by JDBC 4.0. In addition, now VTITemplate and StringColumnVTI appear only in the JDBC3 version of Derby's public api. The JDBC4 version contains the *40 equivalents. While I was in there, re-wrote VTITemplate so that the stubs throw a more informative notImplemented() exception. Note that after this patch is committed, we should hold-off closing this issue. We will want to add a couple methods to the new classes in order to satisfy the JDBC 4.1 (Java 7) contract for ResultSet. Touches the following files: ---------- A java/engine/org/apache/derby/vti/VTITemplate40.java A java/engine/org/apache/derby/vti/StringColumnVTI40.java These classes extend their JDBC 3.0 counterparts but add the new methods introduced by JDBC 4.0. ---------- M java/engine/org/apache/derby/vti/StringColumnVTI.java M java/engine/org/apache/derby/vti/VTITemplate.java Changed the header comments to indicate that these are the JDBC 3.0 versions. Also rewrote VTITemplate to throw more informative exceptions. ---------- M java/engine/org/apache/derby/vti/build.xml Used the appropriate compiler level and libraries for the different JDBC levels. ---------- M tools/javadoc/publishedapi_jdbc3.ant M tools/javadoc/publishedapi_jdbc4.ant M tools/javadoc/publishedapi.ant Made the appropriate classes appear in the JDBC3 and JDBC4 public api. ---------- M tools/jar/extraDBMSclasses.properties Added the new *40 classes to the engine jar file.
        Hide
        Knut Anders Hatlen added a comment -

        That reminds me why we decided not to include a public VTI template class back when we exposed table functions...

        I would prefer a solution that didn't require code changes in the application when moving from one Java version to another. What about having a non-abstract super class of VTITemplate, say VTITemplateBase, that implements the full JDBC 3.0 java.sql.ResultSet interface, and making VTITemplate have abstract overrides of next(), close() and getMetaData()? I think that will stop the compiler from complaining, even if the class doesn't really implement all of the JDBC 4.0 methods.

        Show
        Knut Anders Hatlen added a comment - That reminds me why we decided not to include a public VTI template class back when we exposed table functions... I would prefer a solution that didn't require code changes in the application when moving from one Java version to another. What about having a non-abstract super class of VTITemplate, say VTITemplateBase, that implements the full JDBC 3.0 java.sql.ResultSet interface, and making VTITemplate have abstract overrides of next(), close() and getMetaData()? I think that will stop the compiler from complaining, even if the class doesn't really implement all of the JDBC 4.0 methods.
        Hide
        Rick Hillegas added a comment -

        That's an appealing suggestion, Knut. Thanks, I'll take a look at that.

        Show
        Rick Hillegas added a comment - That's an appealing suggestion, Knut. Thanks, I'll take a look at that.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-05-ab-addJDBC4.0versions.diff. This patch implements Knut's suggestion of creating a non-abstract superclass of VTITemplate. Very sneaky. I will run regression tests.

        With this patch, you should be able to compile under both Java 5 and Java 6 when you extend VTITemplate and StringColumnVTI. There should be no need to add JDBC 4.1 methods to these classes either.

        The public api will include VTITemplate and StringColumnVTI.

        After applying these changes, I was able to use both the Java 5 and Java 6 compilers to build two classes which extend StringColumnVTI: PMDWrapper.java (see DERBY-4927) and RSMDWrapper.java (see DERBY-4926). I was also able to use both compilers to build a simple class which extends VTITemplate.

        Touches the following files:

        --------

        A java/engine/org/apache/derby/vti/VTITemplateBase.java

        New complete implementation of the JDBC 3.0 ResultSet.

        --------

        M java/engine/org/apache/derby/vti/VTITemplate.java

        Abstract subclass

        --------

        M java/engine/org/apache/derby/vti/build.xml

        Adds VTITemplateBase to the JDBC 3.0 build.

        Show
        Rick Hillegas added a comment - Attaching derby-4932-05-ab-addJDBC4.0versions.diff. This patch implements Knut's suggestion of creating a non-abstract superclass of VTITemplate. Very sneaky. I will run regression tests. With this patch, you should be able to compile under both Java 5 and Java 6 when you extend VTITemplate and StringColumnVTI. There should be no need to add JDBC 4.1 methods to these classes either. The public api will include VTITemplate and StringColumnVTI. After applying these changes, I was able to use both the Java 5 and Java 6 compilers to build two classes which extend StringColumnVTI: PMDWrapper.java (see DERBY-4927 ) and RSMDWrapper.java (see DERBY-4926 ). I was also able to use both compilers to build a simple class which extends VTITemplate. Touches the following files: -------- A java/engine/org/apache/derby/vti/VTITemplateBase.java New complete implementation of the JDBC 3.0 ResultSet. -------- M java/engine/org/apache/derby/vti/VTITemplate.java Abstract subclass -------- M java/engine/org/apache/derby/vti/build.xml Adds VTITemplateBase to the JDBC 3.0 build.
        Hide
        Dag H. Wanvik added a comment -

        This looks like a clear usage improvement to me. +1

        Show
        Dag H. Wanvik added a comment - This looks like a clear usage improvement to me. +1
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Rick. Does it also work if we make VTITemplateBase non-public? If so, I think we should do that, since we probably don't want VTITemplateBase to be used directly.

        Show
        Knut Anders Hatlen added a comment - Thanks, Rick. Does it also work if we make VTITemplateBase non-public? If so, I think we should do that, since we probably don't want VTITemplateBase to be used directly.
        Hide
        Rick Hillegas added a comment -

        Thanks for the quick feedback, Dag and Knut. The tests passed cleanly except for known instabilities in testAttributeAccumulatedConnectionCount and testPing. Committed derby-4932-05-ab-addJDBC4.0versions.diff at subversion revision 1044158. I will experiment with making VTITemplateBase non-public tomorrow.

        Show
        Rick Hillegas added a comment - Thanks for the quick feedback, Dag and Knut. The tests passed cleanly except for known instabilities in testAttributeAccumulatedConnectionCount and testPing. Committed derby-4932-05-ab-addJDBC4.0versions.diff at subversion revision 1044158. I will experiment with making VTITemplateBase non-public tomorrow.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-4932-06-aa-packageProtection.diff. This patch gives VTITemplateBase package protection, preventing users from directly extending it. I am running regression tests now.

        Touches the following file:

        M java/engine/org/apache/derby/vti/VTITemplateBase.java

        Show
        Rick Hillegas added a comment - Attaching derby-4932-06-aa-packageProtection.diff. This patch gives VTITemplateBase package protection, preventing users from directly extending it. I am running regression tests now. Touches the following file: M java/engine/org/apache/derby/vti/VTITemplateBase.java
        Hide
        Rick Hillegas added a comment -

        Test passed cleanly for me on derby-4932-06-aa-packageProtection.diff. Committed at subversion revision 1044431.

        Show
        Rick Hillegas added a comment - Test passed cleanly for me on derby-4932-06-aa-packageProtection.diff. Committed at subversion revision 1044431.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development