db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From drv <drvyv...@hotmail.com>
Subject Re: Limitations of Table Functions vs. old VTIs?
Date Wed, 13 Mar 2013 23:30:33 GMT
Hi Rick - yes this is useful, thanks.

Just to follow up on remaining points:

- Regarding the new issue (0) I inserted in my last post: Would it be
reasonable to request some sort of extension to the Table Functions set of
interfaces, to provide the original SQL to Table Functions at runtime (e.g.
before the initScan())? Perhaps another initScan() signature could be
provided that would include the VTIEnvironment? - Also I would be interested
to know what purpose the "sharedState" element of the VTIEnvironment could
have? I have not found anything I could use it for in the past...

- A quick note about the "com.ibm.db2j." package requirement: We have always
had all our VTIs under this package for the reason you stated (certainly up
to Derby 10.5). I have discovered however that with Derby 10.8, the
restriction is no longer there. I believe Derby will now work with VTIs from
any package.

Rick> There might be a way for the Java method to dig up one of the Derby 
contexts and find the SQL text. However, that would not be a supported api.
=> It would be very useful if there was such a "context" I could grab hold
of. Perhaps this context would also have a reference to the original sql as
well as the function name for that particular invocation (note the same SQL
can trigger multiple invocations in the case of a JOIN)... Do you have any
clues on how I might get to this? We have often hoped that the
VTIEnvironment would act as that kind of handle...

- Thanks for the tips on StringColumnVTI, for raising the SYNONYM request
and for the info on existence of VTIs in the longer term... For now I think
we will have to stick with VTIs for our constructs that absolutely require
dynamic table shapes - in particular our VTI class named 'GaianQuery', which
takes a sub-query as argument (which may be any SQL: SELECT, CRUD, Stored
Procedure...) and which is propagated through a GaianDB network of database
nodes and run against any set of targeted nodes.

I appreciate your help. If you are interested in finding out more about the
Gaian Database, our old research release 1.5 (from 2011) is here: 

We also have an in-house Asset release 2.1 - available on request - which
has been significantly hardened.


View this message in context: http://apache-database.10148.n7.nabble.com/Limitations-of-Table-Functions-vs-old-VTIs-tp127988p128096.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

View raw message