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, 03 May 2007 21:09:15 GMT

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

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

Thanks for the continued feedback, Dan.

> Why is the VTIEnvironment class being removed from the VTICosting interface? Does it
cause issues in some way?

I had a couple issues with this class:

1) I don't know what to tell users who want to exploit this argument in their costing logic.
The javadoc is not very helpful. In addition I couldn't find any explanation of this class
in the Cloudscape 3.5 documentation which I consulted: There the class is mentioned as having
been added for future expansion, but the methods are not explained. I could not find any examples
of its actually being used by our diagnostic VTIs.

2) One of the methods in this class, isCompileTime(), seems geared toward the old Cloudscape
VTIs, which were instantiated twice: at compile-time in order to bind() against the signature
of the ResultSet, and at run-time in order to actually loop through the rows. This doesn't
fit the ANSI scheme in which the bind() time information is declared when you CREATE the Function
Table.

> The separation of the creation of the VTICosting object from the creation of the VTI
class means that the costing cannot take into
> account the parameters being passed to the table function. Thus it might be hard for
an application developer to have any meaningful
> costing information, defeating the whole purpose of the interface.
> 
> It also limits the any class to supporting just one static method that returns a ResultSet,
unless they can all share the same exact costing information.

I'm not happy with the flexibility of VTICosting and I welcome brainstorming on this topic.

The signature of the VTICosting instantiator is a tricky issue. Consider the example in my
reply to Army above. Here the arguments to the VTI are not known until run time. In fact,
they change as the query runs and the VTI is re-instantiated for each row in the outer query
block. In this case, what would be the signature of the VTICosting instantiator?

For the moment, let's not worry about where we find the VTICosting instantiator. This could
be a constructor in the Function Table's class, a distinctively named static method in that
class, some other class or method bound to the Function Table via a system procedure, etc..

Instead, let's focus on the signature of the VTICosting instantiator. Here are some possibilities:

A) A 0-arg signature. This is essentially what the current spec proposes.

B) Some Derby interface like VTIEnvironment. The interface would have to be documented extensively.

C) The same signature as the Function Table itself. We would substitute conventional defaults
for arguments which could not be computed at bind() time--like ? parameters and correlated
column references from outer query blocks.

D) A leading prefix of the Function Table's signature. Here we would raise an exception if
one of the leading arguments could not be computed at bind() time.

What are your thoughts?

> 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, 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