[
https://issues.apache.org/jira/browse/DERBY-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969547#action_12969547
]
Knut Anders Hatlen commented on DERBY-4932:
-------------------------------------------
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.
> 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.
