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 Fri, 10 Dec 2010 18:52:19 GMT
Thanks for the quick response, Kathey. Some comments inline...

On 12/10/10 10:09 AM, Kathey Marsden wrote:
> On 12/10/2010 9:46 AM, Rick Hillegas wrote:
>> I am considering adding metadata wrapper functions to the Derby 
>> product. I would like the community's feedback on how to expose these 
>> functions.
> Thank you Rick for this work.  I have not looked closely at it but am 
> wondering if you are proposing that these be exposed as a stable or 
> unstable interface
I don't see much danger that the signatures of the functions will 
change. They are pretty much the signatures of the corresponding 
metadata methods. They might become redundant, though, if someone 
implements the Information Schema. We also might rue our choice of 
system schema and want to move the methods to another schema.
> and also wonder if we have a
> call syscs_util.syscs_load_metadata_wrappers( true ); , if there 
> should also a be an unload or if the load method should reload new 
> definitions.
I was thinking that you would unload the wrappers by invoking the new 
system procedure like this:

call syscs_util.syscs_load_metadata_wrappers( false );

> I can't remember if columns might get added for metadata calls with 
> new JDBC versions.   It seems to me there is some sort of precedence 
> for this. Even if there is just a bug it would be great to be able to 
> drop and reload.
JDBC 4.0 added columns to some of the metadata ResultSets. JDBC 4.1 will 
add a couple new methods to DatabaseMetaData. As you note, we should 
make it possible to unload the old wrappers and load the new ones.
> Again having not looked at this, I don't understand how confident we 
> will never want to change the wrappers, but it might be nice to first 
> just expose them on a Wiki page as unstable and subject to change 
> until they have been vetted
> instead of putting them in the formal documentation right away.  
> Pardon my fear of compatibility commitments #:)
I share your concern about creating new compatibility commitments for a 
large api. Documenting this on the wiki as an experimental feature 
sounds prudent to me. This would discourage 3rd parties from building 
tools using these wrappers. However, we would still be able to use the 
methods ourselves and we could cite them in our tech support responses.

> Thanks
> Kathey

View raw message