db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
Date Tue, 20 May 2008 17:15:55 GMT

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

Rick Hillegas commented on DERBY-3676:

>2. As a consequence I guess I've missed something obvious - this would have been a Patch
to PreparedStatement.java. I'm not quite following yours and Knuts comments about EmbedPreparedStatement,
probably because I in fact "cowboy-programmed" it (just searched for PreparedStatement.java
in fact.

Ah, it sounds like your changes were intended for org.apache.derby.client.am.PreparedStatement.
That's the PreparedStatement implementation in Derby's client driver. Derby also has an embedded
driver. For some reason I thought you were working in the embedded driver. That may just be
because the original email thread talked about embedded usage.

>1. Also, If I understand correctly, you are saying there's no way to expose this info
if runnning the client driver (I guess that makes some sense sadly, the info would be on the
server side)?

Happily for you, you are already working in the client driver. So instead of EmbeddedDriver,
you could put a forwarding method in ClientDriver.

>2. And if it were moved to EmbeddedDriver, how would one make it thread safe (before I
was following the other methods in the class and syncing on connection)? I mean those are
ugly public thingies? I know a Connection isn't thread safe by JDBC, and I guess that implies
PreparedStatements aren't either, too though. But assumedly there was good reason for syncing
on Connection? Or was this an abortive attempt to achieve a thread-safe driver?

After forwarding, couldn't you rely on the synchronization you have already coded? I would
follow the pattern that's already in the code. If there's something wrong with the synchronization,
then regularity will help the fixer find all instances of the problem.

> 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.

View raw message