db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: productizing the metadata wrapper functions
Date Mon, 13 Dec 2010 14:24:41 GMT
Thanks for continuing the discussion, Bryan. Some more comments inline...

On 12/10/10 8:27 PM, Bryan Pendleton wrote:
>> These wrapper functions let you use SQL to examine
>> database, ResultSet, and parameter metadata.
> The database metadata table function seems quite natural and powerful.
> I'm less clear on how to use the RS and Parameter functions; I looked
> at the examples in DERBY-4926 and DERBY-4927 but they seemed pretty
> artificial. Do you have more substantial examples? Also, would these
> latter two functions be useful in a JDBC program? Or are they something
> that would mostly be useful in IJ?
Agreed, it's harder to come up with use-cases for the RS and PMD 
examples. I have found them useful for using ij to measure a database's 
JDBC compliance. These functions don't add much value to a Java program. 
We could leave them out.
> I guess what I'm asking is: could I somehow pass an actual ResultSet
> object or PreparedStatement object to one of these functions? Or do
> they always have to take a query string and compile it themselves?
They take a query string.
> Lastly, why does it take several seconds to register these functions?
> Is it due to how they are packaged? (That is, if they were embedded
> in derby.jar would the registration go faster?) I'm a bit surprised
> that something as seemingly trivial as registering three table
> functions could take that much time.
Right. Sorry for not explaining this in greater depth. A wrapper 
function is registered for each method in DatabaseMetaData. So that's 
about 170 functions which have to be registered. I think that if they 
were directly registered by DataDictionaryImpl, it would be faster--that 
would just involve stuffing 170 rows into a catalog. What I was 
measuring was registration via a series of compiled CREATE FUNCTION 
statements. There's some compiler overhead here.

> Anyway, thanks very much for doing this work, and for advancing the
> proposal; it's quite interesting and I've been learning a lot by
> reading your work and following the discussions!
> bryan

View raw message