db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: [jira] [Commented] (DERBY-484) Documentation for derby.database.classpath in developers guide is misleading
Date Wed, 11 May 2011 16:40:06 GMT
"Kim Haase (JIRA)" <jira@apache.org> writes:

> 2) A pointer to the exact topic(s) on SQLJ.INSTALL_JAR are a good
> idea. This procedure is shown briefly in the Dev Guide

Yes, at first I actually didn't understand the property explanation at
all before I read the explanation in ttoolsjarload1002986.html: the
crucial fact that the externally named jar-files are given a legal
schema qualified SQL identifier name in that process. If you miss that
fact, the explanation of the property doesn't make much sense, so yes, a
pointer would be good, with a hint to "why the jar-files' names don't
look like file names, please see link".

> I wonder where the documentation of these procedures actually
> belongs. (SQLJ.REMOVE_JAR and SQLJ.REPLACE_JAR are the others.) What
> kind of procedures are they? The only system procedures and functions
> we document in the Reference Manual are the SYSCS_UTIL ones. Should
> the basic reference info on the SQLJ ones be moved to the Reference
> Manual?

This has always confuses me. I like all my detailed technical
information to be available in the reference manual, if not necessary
readable for a newbie. Other guides should be task centered IMHO:
Administration, tuning, getting to know... etc. A prior, I am all for
it, but it may upset the total structure.. what do people think?
At the very least, the reference manual should contain entries for all
builtin procedures with links to the tools manual we we choose to keep
the explanations there.

> 3) I just realized that I ignored one of the original problems
> reported in the issue, that the statement "The first time you set the
> property, you must reboot to load the classes" is not true. If this is
> in fact the case, the property is truly dynamic, and I should change
> http://db.apache.org/derby/docs/devguide/cdevdeploy21645.html ("Enable
> database class loading with a property" too.

I don't know how this feature really work, I'd need to experiment to
find out. Does anybody know for sure how we behave here?


>> Documentation for derby.database.classpath in developers guide is misleading
>> ----------------------------------------------------------------------------
>>                 Key: DERBY-484
>>                 URL: https://issues.apache.org/jira/browse/DERBY-484
>>             Project: Derby
>>          Issue Type: Bug
>>          Components: Documentation
>>    Affects Versions:
>>            Reporter: Daniel John Debrunner
>>            Assignee: Kim Haase
>>            Priority: Minor
>>         Attachments: DERBY-484.diff, DERBY-484.stat, DERBY-484.zip, cdevdeploy21645.html,
>> 10.1 alpha docs (from site)
>> http://db.apache.org/derby/docs/devguide/cdevdeploy21645.html
>> 1) Remove sentence 'The first time you set the property, you must reboot to load
the classes.' 
>>      This is not true and is tested with lang/dcl.sql
>> 2)  This implies there is more infomation in the tuning guide, but I don't see any.
>> 'See "derby.database.classpath" in Tuning Derby for more information about the property.'
>> Searching the tuning guide I find no mention of derby.database.classpath
>> http://db.apache.org/derby/docs/tuning/tuningderby.pdf
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message