Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <6761851.1178226555736.JavaMail.jira@brutus>
Date: Thu, 3 May 2007 14:09: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_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.