db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Westerfeld, Kurt" <kwesterf...@managedobjects.com>
Subject RE: Re-enabling VTIs
Date Fri, 18 Nov 2005 01:27:43 GMT
I for one, see the power of this feature and welcome it back in the
fold.  We are moving in a direction that would either 1) place our own
VTIs under the diag namespace (ugly) or 2) shipping a slightly modified
form (ugly) or 3) petitioning to get this added back in.  

The VTI API should have the ability to:
 - get at the full qualifier list of the given query (right now, it gets
partial list depending on what operators are used)
 - IQualifier needs to be a notify API, not a "you must do all
filtering" API (see enhanceement 703).
 - How do joins get indicated if the VTI can quickly build a hashed
lookup on an identifier?  IN other words, if I have a data structure
that is indexed somehow, and the VTI is exposing that data, and then is
joined with another similar VTI, can the engine take advantage of an
 - I would like the VTI to be exposed in the metadata of the database
 - I need the current syntax to be kept or augmented without removing
the ability to parameterize a VTI.

Thanks....maybe I'll think of more!

-----Original Message-----
From: Rick Hillegas [mailto:Richard.Hillegas@Sun.COM] 
Sent: Thursday, November 17, 2005 7:26 PM
To: Derby Development
Subject: Re-enabling VTIs

I have logged enhancement request 716 to track the re-enabling of 
customer-defined Virtual Table Interfaces (VTIs). A little history

Cloudscape used to let users include arbitrary customer written 
ResultSets in the FROM lists of queries. This provided a very powerful 
ability to impose a tabular face on external data and to join relational

data with external data streams. It is hard to overestimate the 
usefulness of this feature. Today, Derby still ships a number of 
diagnostic VTIs. However, customer-written VTIs have been disabled. The 
parser raises an error when it sees a VTI that doesn't live in Derby's 
diagnostic packages.

I would like to develop a plan for addressing the concerns which led to 
the disabling of this feature. I would like to see us put this power 
back in our customer's hands.

I can imagine that the non-standard nature of VTI declaration was an 
issue. Are there other issues? Has anyone given some thought to what a 
more acceptable API would look like?


View raw message