Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <5442283.1177014555551.JavaMail.jira@brutus>
Date: Thu, 19 Apr 2007 13:29:15 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-716) Re-enable VTIs
In-Reply-To: <1393942992.1132272881534.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490163 ] 

Rick Hillegas commented on DERBY-716:
-------------------------------------

Thanks again for the feedback, Dan.

Dan> I think the parameter style should be more specific than "DERBY", say "DERBY_JDBC_RESULT_SET", there may be other Derby specific types that could be added here, e.g. RSS.

Sounds good to me. Maybe something shorter like DERBY_JDBC.

Dan >"When you issue a query against a Table Function, Derby constructs a ResultSetMetaData for the result, based on the column names and datatypes you declared when you initially created the Table Dan >Function."
Dan >  Not sure what this is really trying to say. Why would Derby create a ResultSetMetaData based upon the functions shape, what is this used for?

I will clarify this in the next rev of the spec. Here's the point I was trying to make. Please let me know if this is still confusing: The user will write a VTI, say myVTI. When the user issues "select * from TABLE( myVTI( ... ) )", Derby will hand back a ResultSet, say an EmbedResultSet20. The original CREATE FUNCTION statement determines the shape of the metadata returned by EmbedResultSet20 regardless of the shape of the metadata returned by myVTI.getResultSetMetaData().

Dan >I don't see from the functional specification how VTICosting is tied in? What does the app developer do?

Thanks, I will explain this in the next rev of the spec.

Dan > How about the Pushable interface, that's useful existing functionality as well?

I don't see any implementations of Pushable in the Derby diagnostic VTIs. Was this interface ever really used or is it, like VTIEnvironment, part of someone's future plans?

In any event, I was only spec'ing read-only table functions, that is, ones that implement ResultSet. From its javadoc, Pushable seems to apply to read-write VTIs that implement PreparedStatement.


> Re-enable VTIs
> --------------
>
>                 Key: DERBY-716
>                 URL: https://issues.apache.org/jira/browse/DERBY-716
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>            Reporter: Rick Hillegas
>         Attachments: functionTables.html
>
>
> Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages.
> This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands.

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