[
https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598303#action_12598303
]
Rick Hillegas commented on DERBY-3676:
--------------------------------------
Hi Mike,
Thanks for submitting this code and for adding the extra check for
uninitialized parameters. Just as a heads up, the community likes to see
patches which reviewers can easily apply using the subversion tools. Please
don't take this as a criticism or be put off by the process. It's really easy
and it really helps the committers do their work. The process for generating a
patch is described in the section titled "Contribute Code or Documentation" on
this web page: http://db.apache.org/derby/derby_comm.html
Some responses to your comments:
>Boy, I'm a java newbie, but I was inspired to look at the code after Rick's
>encouraging comments on the list. . It looks easy to do, but the BUILDING
>looks......painful, judging from BUILDING.txt
Right. The Derby build is too complicated. The complexity discourages newcomers
and the community needs to put more effort into simplifying the build. Thanks
for sticking with it!
>Comment 1. Isn't it bad practice in general to do what Daniel says the code is
>doing, eg rely on toString() for ANY formal meaning? I don't mean this as
>criticism, just curious.
Yes, I think that's what the textbooks recommend. As you dig into Derby, you
will discover some old code that dates from the period when people were
learning these lessons the hard way.
>Comment 2. If toString is being used anyway, why not just use toHumanString()
Sounds good to me.
Now for a little more conversation about the problem and the patch. It looks
like you've coded Thomas' suggestion. What you've coded looks good and can be
used by an application which does something like this:
String queryText = ((EmbedPreparedStatement)
preparedStatement).toHumanString();
That's well and fine for a piece of internal code. I think it's great
incremental improvement.
A follow-on patch could be one which wires this internal api into Derby's
public api. If you're interested, please read on...
To help developers understand what api's are stable and can't change from
release to release, Derby collects all of its public api into the classes
visible in the JDBC3 and JDBC4 javadoc. You can see what's in the public api by
building the following target after building the Derby classes:
ant publishedapi
If you want applications to be able to rely on your code, then you will want to
add some forwarding method to the public api. I've made a suggestion about what
this forwarding method might look like (see my May 16 comment). So far that's
the only suggestion. You may come up with a better idea.
> Make the toString() method of Derby PreparedStatements print out SQL text
> with ? parameters replaced by the values that have been set so far
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3676
> URL: https://issues.apache.org/jira/browse/DERBY-3676
> Project: Derby
> Issue Type: New Feature
> Components: JDBC, Newcomer
> Reporter: Rick Hillegas
> Attachments: ick.txt, ick.txt
>
>
> This topic came up in the following email thread on the user list:
> http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811
> Here's what the thread requests:
> "In mysql, a toString() on a PreparedStatement will do this, eg "select x
> from foo where x.a = ?" will become "select x from foo where x.a = 1" with
> the appropriate setValue() call."
> At first blush, this seems like it might be a simple project for a newcomer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
