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 19:27:15 GMT

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

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

Thanks for the continued feedback, Army.

> 1) Under "Additional SELECT Syntax" 

I welcome additional ideas about how to wordsmith this. I'm trying to accomplish the following:

a) Indicate that I'm not planning to support any syntax that doesn't currently work for the
diagnostic vtis--at the same time, I'm not planning to disable anything that is useful and
already implemented.

b) Sketch what can be said about this in the user manuals.

I think I have accomplished (a) but I agree that (b) is a bit fuzzy. To me, the wording that
you suggest doesn't cover the following case:

select s.schemaName, t.tableName
from sys.sysschemas s, sys.systables t
where t.schemaid=s.schemaid
and exists
(
   select vti.*
   from table ( syscs_diag.space_table( s.schemaName, t.tableName ) ) as vti
   where vti.numfreepages > 100
);

Here the arguments to the VTI constructor are variables in the context of the outer query
block but constants in the context of the inner block. What do you think of something like
the following: "Table Function arguments must resolve to expressions which are evaluated once
in the context of their query block. This includes literals and ? parameters but may also
include the return values of function calls as well as correlated references to columns in
outer query blocks."

> 2) Under "Appendix E: Sample VTI" 

I am sorry that this is so confusing. In my example, I am admitedly waving my hands over the
complexity of managing connections to an external database. This is not how someone would
really write this VTI. In additon to the awkwardness of closing down the whole VTI, this example
is simply not re-entrant: If two different connections tried to use this VTI, they would trip
over one another. Writing a bullet-proof VTI like this requires some work, which I think someone
will want to do (and hopefully donate to the community). I'm not taking on that task as part
of writing this functional spec. I will add some words to note that I'm waving my hands here.


> 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