You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/11/11 05:19:19 UTC
[lang] StringUtils proposed methods
Going over Ken Fitzpatrick's suggested new methods:
getClassNameOnly( Object o ) : String => ClassUtils.getClassNameOnly. DONE
+++++++++++++++++++++++++++++++++++++++++++++++
getNumerics( String s ) : String /** Returns only the numeric contents of s */
+++++++++++++++++++++++++++++++++++++++++++++++
getProperCase( String s ) : String /** Returns proper-case equivalent of
the
contents of s (ex: return "Bob Smith" from "bob smith") */
+++++++++++++++++++++++++++++++++++++++++++++++
getBoolean( String s ) : boolean - Already Added :) DONE. Doesn't do t/f,
y/n, 1/0, +/-, Yep/Nope etc.
+++++++++++++++++++++++++++++++++++++++++++++++
getTrueOrFalse( boolean b ) : String /** Returns the equivalent of b as
either "True" or "False" */ ... other methods to support inverse of
previous
method (ex: getYesOrNo, getOnOrOff, etc.)
I guess. Seems a bit weak :) I'm not a big ternary fan, but:
b ? "Yes" : "No" seems simple. Or a simple if/else. Or ChoiceFormat?
Dunno. N methods seem a bit poor. And ""+b will give true/false.
+++++++++++++++++++++++++++++++++++++++++++++++
concatWithConditionalIntermediate - Ordinarily I'd have pooh-poohed this
one. But it's the second time it's been suggested. It's basically a join
that handles empty elements specially.
+++++++++++++++++++++++++++++++++++++++++++++++
getHexCharsToByteArray. This was around. ByteArrays class. I've got it
still sitting on my local repo. I think it went to Lang from Util then to
Codec or something silly. I still think it's useful, but it's been vetoed
in the past.
+++++++++++++++++++++++++++++++++++++++++++++++
getValueSubstitutedString. This is an instance of Interpolator in
Commons-Sandbox Util.
+++++++++++++++++++++++++++++++++++++++++++++++
getDumpFormat. I thought this was in Util, or Codec, or somewhere..
HexDump class.
+++++++++++++++++++++++++++++++++++++++++++++++
getCharValue - Turn a String like "31" into the character that equals,
"1". I think this is too specific, and not hard to do anyway.
""+(char)NumberUtils.stringToInt("31");
or something??
+++++++++++++++++++++++++++++++++++++++++++++++
SQL
===
getSqlEscapedColumnValue( String s ) : String /** Returns an SQL-based
escaped
equivalent of s (ex: map "Bob's" to "Bob''s", etc.) */
+++++++++++++++++++++++++++++++++++++++++++++++
getSqlWhereEqualsColumnValueOrIsNull( String s ) : String /** Returns "=
'[s]'"
(if s != null) or "is null" (if s == null) for safely building SQL Where
Clause
Predicates like "ColumnName = 'Bob'" or "ColumnName is null" */
+++++++++++++++++++++++++++++++++++++++++++++++
getSqlColumnValueOrNull( String s ) : String /** Returns s or the String
"null"
such that the returned value can be used to safely build an SQL Update.Set
Clause, Insert.Values Clause, etc. as "Set Col=[s]" where s is the value
returned from this method ... Overloads for Date, Integer, ... */
I'm interested in all three of these Sql methods being added to DbUtils in
the Commons-Sandbox :) Could you provide your implemetnations Ken?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [dbutils] StringUtils proposed methods
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 11 Nov 2002, Joe Germuska wrote:
> 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
> http://www.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html, tip #3)
>
> * 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.
[P6Spy! though it's not quite there yet with the log rolling stuff]
> 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...
Yeah. Am convinced that they would be of use in DbUtil class, or a
DbStringUtil.class.
Want to send your implementation in Ken? As I'm inherently lazy
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [dbutils] StringUtils proposed methods
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 11 Nov 2002, Craig R. McClanahan wrote:
> 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, though.
>From OReilly's Oracle JDBC book:
"...it takes about 65 iterations of a prepared statement before its total
time for execution catches up with a statement. "
> 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.
This is the same reason I push the 'java lie to newbies' that they should
use PreparedStatement all the time. No learning about date-syntax for a
particular database, no worrying about escaping.
If all databases now support '' as the escape mechanism properly, then
that's good and we should have it. If there is a standard date-format that
does work, then good.
I guess we could have:
Sql99Utils as a method, so it's obvious that some db's might not support
it.
> It is tedious, error-prone, and non-portable to require application
> developers to deal with this kind of thing themselves.
Hear hear :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [dbutils] StringUtils proposed methods
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 11 Nov 2002, Joe Germuska wrote:
> Date: Mon, 11 Nov 2002 11:40:01 -0600
> From: Joe Germuska <Jo...@Germuska.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> 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
> http://www.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html, 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,
though.
> * 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
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [dbutils] StringUtils proposed methods
Posted by Joe Germuska <Jo...@Germuska.com>.
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
http://www.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html, tip #3)
* 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.
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...
Joe
--
--
* Joe Germuska { joe@germuska.com }
"It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble.... As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records."
--Sam Goody, 1956
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[dbutils] StringUtils proposed methods
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 10 Nov 2002, Henri Yandell wrote:
> Going over Ken Fitzpatrick's suggested new methods:
>
> +++++++++++++++++++++++++++++++++++++++++++++++
> SQL
> ===
>
> getSqlEscapedColumnValue( String s ) : String /** Returns an SQL-based
> escaped
> equivalent of s (ex: map "Bob's" to "Bob''s", etc.) */
>
> +++++++++++++++++++++++++++++++++++++++++++++++
>
> getSqlWhereEqualsColumnValueOrIsNull( String s ) : String /** Returns "=
> '[s]'"
> (if s != null) or "is null" (if s == null) for safely building SQL Where
> Clause
> Predicates like "ColumnName = 'Bob'" or "ColumnName is null" */
>
> +++++++++++++++++++++++++++++++++++++++++++++++
>
> getSqlColumnValueOrNull( String s ) : String /** Returns s or the String
> "null"
> such that the returned value can be used to safely build an SQL Update.Set
> Clause, Insert.Values Clause, etc. as "Set Col=[s]" where s is the value
> returned from this method ... Overloads for Date, Integer, ... */
>
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?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>