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 index? - 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:[EMAIL PROTECTED] 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 follows: 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? Thanks, -Rick
