Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <17810021.26411291849680911.JavaMail.jira@thor>
Date: Wed, 8 Dec 2010 18:08:00 -0500 (EST)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4932) Move the StringColumnVTI to the
 public api
In-Reply-To: <2785581.3021291663028796.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.