commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [dbutils] StringUtils proposed methods
Date Mon, 11 Nov 2002 19:00:30 GMT

On Mon, 11 Nov 2002, Joe Germuska wrote:

> Date: Mon, 11 Nov 2002 11:40:01 -0600
> From: Joe Germuska <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [dbutils] StringUtils proposed methods
> At 12:23 PM -0500 2002/11/11, Henri Yandell wrote:
> >Looking at these, it seems that the first and third are easier done by
> >using a PreparedStatement, which knows more about exactly how the
> >particular database likes to escape a ' etc.
> >
> >Is there a big need to provide a String method here, or should people just
> >be upgrading to the PreparedStatement?
> I have two reasons for building SQL statements from strings instead
> of using prepared statements:
> * if you're not iterating through repeated queries, the overhead of
> creating a prepared statement is wasted -- this isn't a critical
> optimization, but it is one argument against using prepared
> statements for one-off queries.  (See
>, tip #3)

In at least a couple of popular open source JDBC drivers (at various times
-- haven't looked lately), the implementation of the String based calls
just used the prepared statement logic underneath the covers, so the
"extra overhead" was zero.  That's probably not true for Oracle's driver,

> * When developing, it can be substantially easier to debug JDBC
> problems when you can see the values which were used in the SQL
> statement; this is easier done by printing a complete SQL statement
> than by reconstructing it.

Fair point, but has to be balanced with a negative (see below).

> I think these are pretty good reasons for leaving the choice up to
> users of the library, instead of steering people straight to
> PreparedStatements in all cases...

The primary reason I encourage people to use prepared statements *all* the
time is so that the poor user doesn't have to learn things like the quote
escaping mechanisms (often database specific) so that names like
"O'Reilly"  can be stored in a text column.  Same thing in spades for all
of the wierd date conversions that some databases require.

It is tedious, error-prone, and non-portable to require application
developers to deal with this kind of thing themselves.

> Joe


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message