db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6022) Add a system procedure for (un)registering optional packages of Derby tools.
Date Thu, 03 Jan 2013 05:44:13 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13542731#comment-13542731

Dag H. Wanvik commented on DERBY-6022:

Thanks, Rick. Seems useful to me. Now, 

So, the dbmdwrapper tool wouldn't live in derbytools.jar - as an exception? If our first use
case for an optional tool doesn't fit there, maybe we will have to solve this ad hoc going

Recapping a bit, in the description you say "tools which wouldn't be checked in the to main
code line", but if they are to be bundled with our jars, shouldn't they be? Sorry if I am
a little confused here.. next question, if they *are* checked into the main code line and
bundled in one of our jars, what would be the argument for *not* auto-registering them? Name
space pollution?
> Add a system procedure for (un)registering optional packages of Derby tools.
> ----------------------------------------------------------------------------
>                 Key: DERBY-6022
>                 URL: https://issues.apache.org/jira/browse/DERBY-6022
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Tools
>    Affects Versions:
>            Reporter: Rick Hillegas
>         Attachments: derby-6022-01-aa-registerToolProc.diff, derby-6022-02-aa-dbmdWrapper.diff
> Now that vararg routines have been added to Derby (see DERBY-3069), I would like to add
a new vararg system procedure for registering and unregistering optional packages of Derby
tools. For starters, these would be tools which aren't checked into the Derby codeline but
are just attached to various JIRAs. These tools are:
> o DBMDWrapper (DERBY-3973 and DERBY-5967) - This tool creates functions and table functions
for all of the DatabaseMetaData methods so that you can write complicated queries which join
and filter JDBC metadata.
> o ForeignTableVTI (DERBY-4962) - This tool creates views against foreign databases so
that you can bulk-import foreign data into Derby without indirecting through csv files.
> It also may be possible to use this approach to expose the log and data file reading
tools attached to DERBY-5195 and DERBY-5201.
> The new system procedure would look like this:
> create procedure syscs_util.syscs_register_tool
> (
>     toolName varchar( 32672 ),
>     boolean register,
>     optionalArgs varchar( 32672 ) ...
> )
> language java parameter style derby modifies sql data
> external name 'willFigureOutWhereToPutThis';
> The arguments would have these meanings:
> o toolName - A name specific to the tool.
> o register - True means "register the tool" and false means "unregister the tool".
> o optionalArgs - Each tool could have its own variable set of additional configuration
> By default, only the DBO could run this procedure. The DBO could grant execute permission
to other users.
> The known tool names and their optional parameters would be documented in the Derby Reference
Manual in the section on syscs_util.syscs_register_tool.
> I am thinking that we should put the optional tools themselves in derbytools.jar. We
might want to document all of the optional tools in the Tools Guide, although I can see arguments
for documenting some tools in the Admin Guide.
> I would appreciate other people's thoughts about this proposal.
> Thanks,
> -Rick

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message