db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4932) Move the StringColumnVTI to the public api
Date Wed, 08 Dec 2010 20:07:01 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-4932:
---------------------------------

    Attachment: derby-4932-05-aa-addJDBC4.0versions.diff

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.


> Move the StringColumnVTI to the public api
> ------------------------------------------
>
>                 Key: DERBY-4932
>                 URL: https://issues.apache.org/jira/browse/DERBY-4932
>             Project: Derby
>          Issue Type: Improvement
>          Components: Javadoc, SQL, Tools
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>            Priority: Minor
>         Attachments: derby-4932-01-aa-exposeVTITemplate.diff, derby-4932-02-aa-moveStringColumnVTI.diff,
derby-4932-02-ab-moveStringColumnVTI.diff, derby-4932-03-aa-useInMemoryDBinDemos.diff, derby-4932-04-aa-retireDemoVersion.diff,
derby-4932-05-aa-addJDBC4.0versions.diff
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message