db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-716) Re-enable VTIs
Date Fri, 20 Apr 2007 14:14:20 GMT
Thanks, Dan. This is all useful feedback and will help make the next rev 
of the spec clearer.

Regards,
-Rick

Daniel John Debrunner wrote:
> Rick Hillegas (JIRA) wrote:
>
>> 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.
>
> Well, VTI's can also be written using PreparedStatement's, so that's 
> why I added the RESULT_SET portion.
>
>>
>> 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().
>
> The point is valid but not in terms of mentioning JDBC ResultSet or 
> ResultSetMetaData. This is SQL, a table function defines a table 
> expression and its column types will be those defined by the function. 
> The types for JDBC are defined by the select list, not the function 
> definition directly, i.e. table functions can be used in more than a 
> SELECT *.
>
>> 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?
>
> Yes, it was used and worked, it's a useful addition, especially if the 
> ResultSet is coming from a back-end SQL database.
>>
>> 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.
>
> OK, also the api I think you are proposing would preclude Pushable, 
> though maybe it can use the same mechanism as the costing api.
>
> Note though that I wouldn't think of the VTIs as ResultSet=Readonly 
> and PreparedStatement=Read-write. The use of PreparedStatement gives 
> one a much cleaner separation between compile time and execute time, 
> something that is very beneficial, even for read-only virtual tables.
>
> Dan.
>


Mime
View raw message