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] Commented: (DERBY-716) Re-enable VTIs
Date Thu, 19 Apr 2007 20:29:15 GMT

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


Mime
View raw message