You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Jeff Levitt <de...@mylevita.com> on 2005/12/10 01:02:42 UTC
Derby-391
Hi all,
Derby-391 has a comment in it that I'd like to
separate out into a new issue.
http://issues.apache.org/jira/browse/DERBY-391
John Embretsen writes:
"I believe the following boolean ij properties are not
mentioned in the documentation (tools guide) either:
ij.showNoConnectionsAtStart
ij.showNoCountForSelect
(I noticed that these properties are used in
trunk/java/tools/org/apache/derby/impl/tools/ij/utilMain.java)"
I would like to create a new JIRA issue and place
John's comment there, because I do not have enough
information yet to create the documentation for those
properties. However, I do have enough to create
documentation for the first three properties mentioned
in this issue, and I would like to submit a patch to
add those and resolve this issue if approved. This
way, the patch does not get held up. Does anyone have
any objections to that? John? If not, I'll create
the new issue, add a comment to it asking for more
info (that I can use very soon to add docs for if
someone provides that info) and then add a comment to
this issue referring to the new one. Finally, I can
submit a patch for this issue :)
Re: Derby-391
Posted by John Embretsen <Jo...@Sun.COM>.
Saturday, December 10, 2005, 1:16:24 AM, Daniel John Debrunner wrote:
> Jeff Levitt wrote:
>> Hi all,
>>
>> Derby-391 has a comment in it that I'd like to
>> separate out into a new issue.
>>
>> http://issues.apache.org/jira/browse/DERBY-391
>>
>> John Embretsen writes:
>> "I believe the following boolean ij properties are not
>> mentioned in the documentation (tools guide) either:
>> ij.showNoConnectionsAtStart
>> ij.showNoCountForSelect
>> (I noticed that these properties are used in
>> trunk/java/tools/org/apache/derby/impl/tools/ij/utilMain.java)"
>>
>>
>>
>> I would like to create a new JIRA issue and place
>> John's comment there, because I do not have enough
>> information yet to create the documentation for those
>> properties. However, I do have enough to create
>> documentation for the first three properties mentioned
>> in this issue, and I would like to submit a patch to
>> add those and resolve this issue if approved. This
>> way, the patch does not get held up. Does anyone have
>> any objections to that? John? If not, I'll create
>> the new issue, add a comment to it asking for more
>> info (that I can use very soon to add docs for if
>> someone provides that info) and then add a comment to
>> this issue referring to the new one. Finally, I can
>> submit a patch for this issue :)
> You could also submit a patch for the first three properties and leave
> the issue open. Incremental development applies to the documentation as
> well as the code.
> Dan.
Either way is fine with me.
I commented the issue because I came across those properties a while
back, and I could not find any mention of them in the documentation
(and I hate when that happens ;) ). I am not sure whether or not
they are meant to be used by Derby users/administrators/testers, but if
they are, they should be documented. I'm sure there are other cases like
this out there too.
--
John
Re: Derby-391
Posted by Jeff Levitt <de...@mylevita.com>.
--- Daniel John Debrunner <dj...@debrunners.com> wrote:
> Jeff Levitt wrote:
>
> > Hi all,
> >
> > Derby-391 has a comment in it that I'd like to
> > separate out into a new issue.
> >
> > http://issues.apache.org/jira/browse/DERBY-391
> >
> > John Embretsen writes:
> > "I believe the following boolean ij properties are
> not
> > mentioned in the documentation (tools guide)
> either:
> > ij.showNoConnectionsAtStart
> > ij.showNoCountForSelect
> > (I noticed that these properties are used in
> >
>
trunk/java/tools/org/apache/derby/impl/tools/ij/utilMain.java)"
> >
> >
> >
> > I would like to create a new JIRA issue and place
> > John's comment there, because I do not have enough
> > information yet to create the documentation for
> those
> > properties. However, I do have enough to create
> > documentation for the first three properties
> mentioned
> > in this issue, and I would like to submit a patch
> to
> > add those and resolve this issue if approved.
> This
> > way, the patch does not get held up. Does anyone
> have
> > any objections to that? John? If not, I'll
> create
> > the new issue, add a comment to it asking for more
> > info (that I can use very soon to add docs for if
> > someone provides that info) and then add a comment
> to
> > this issue referring to the new one. Finally, I
> can
> > submit a patch for this issue :)
>
>
> You could also submit a patch for the first three
> properties and leave
> the issue open. Incremental development applies to
> the documentation as
> well as the code.
>
> Dan.
>
>
>
Sounds reasonable. I'll submit the patch then.
Thanks!
Re: Derby-391
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeff Levitt wrote:
> Hi all,
>
> Derby-391 has a comment in it that I'd like to
> separate out into a new issue.
>
> http://issues.apache.org/jira/browse/DERBY-391
>
> John Embretsen writes:
> "I believe the following boolean ij properties are not
> mentioned in the documentation (tools guide) either:
> ij.showNoConnectionsAtStart
> ij.showNoCountForSelect
> (I noticed that these properties are used in
> trunk/java/tools/org/apache/derby/impl/tools/ij/utilMain.java)"
>
>
>
> I would like to create a new JIRA issue and place
> John's comment there, because I do not have enough
> information yet to create the documentation for those
> properties. However, I do have enough to create
> documentation for the first three properties mentioned
> in this issue, and I would like to submit a patch to
> add those and resolve this issue if approved. This
> way, the patch does not get held up. Does anyone have
> any objections to that? John? If not, I'll create
> the new issue, add a comment to it asking for more
> info (that I can use very soon to add docs for if
> someone provides that info) and then add a comment to
> this issue referring to the new one. Finally, I can
> submit a patch for this issue :)
You could also submit a patch for the first three properties and leave
the issue open. Incremental development applies to the documentation as
well as the code.
Dan.