You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Ken Fitzpatrick <Ke...@KenFitzpatrick.com> on 2002/11/29 04:28:13 UTC

[BeanUtils] ResultSetDynaSet Lower-Case Property Names

The ResultSetDynaSet returns DynaBeans whose PropertyNames are based on 
the ColumnNames of the ResultSet, but converted to all lower-case 
letters.  In general, I agree with Craig's comment that this creates a 
known result in an environment where ColumnName standards vary between 
DBMSs (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14796).  

However, if a target JavaBean class were to be defined 
with PropertyNames that are based on those same ColumnNames, it wouldn't 
seem to be the natural course of action for those PropertyNames to 
consist of all lower-case letters.  The natural thing would seem to be 
for the PropertyNames to have mixed upper- and lower-case letters, as 
appropriate.

If the objective is to have instances of a given JavaBean class returned 
from the SQL operation, the PropertyUtils.copy( destJavaBean, 
resultSetDynaSetDynaBean ) method seems to be the obvious choice. 
 However, since the PropertyNames of the resultSetDynaSetDynaBean 
consist of only lower-case letters, some of those properties won't match 
the mixed-case PropertyNames of the JavaBean, and some of the properties 
won't be copied.

If I am misunderstanding the problem, of if I am creating a problem 
where none really exists, please advise.  Otherwise, I've got some 
classes that I could contribute that would bridge that gap.

Thanks!
Ken Fitzpatrick



Re: [BeanUtils] ResultSetDynaSet Lower-Case Property Names

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Thu, 28 Nov 2002, Ken Fitzpatrick wrote:

> Date: Thu, 28 Nov 2002 21:28:13 -0600
> From: Ken Fitzpatrick <Ke...@KenFitzpatrick.com>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>,
>      Ken@KenFitzpatrick.com
> To: commons-user@jakarta.apache.org
> Subject: [BeanUtils] ResultSetDynaSet Lower-Case Property Names
>
> The ResultSetDynaSet returns DynaBeans whose PropertyNames are based on
> the ColumnNames of the ResultSet, but converted to all lower-case
> letters.  In general, I agree with Craig's comment that this creates a
> known result in an environment where ColumnName standards vary between
> DBMSs (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14796).
>
> However, if a target JavaBean class were to be defined
> with PropertyNames that are based on those same ColumnNames, it wouldn't
> seem to be the natural course of action for those PropertyNames to
> consist of all lower-case letters.  The natural thing would seem to be
> for the PropertyNames to have mixed upper- and lower-case letters, as
> appropriate.
>

You can easily have your cake and eat it too, by using a corresponding
BeanInfo class that describes what the getter and setter method names
really are.  See the JavaBeans spec for more information.

> If the objective is to have instances of a given JavaBean class returned
> from the SQL operation, the PropertyUtils.copy( destJavaBean,
> resultSetDynaSetDynaBean ) method seems to be the obvious choice.
>  However, since the PropertyNames of the resultSetDynaSetDynaBean
> consist of only lower-case letters, some of those properties won't match
> the mixed-case PropertyNames of the JavaBean, and some of the properties
> won't be copied.
>
> If I am misunderstanding the problem, of if I am creating a problem
> where none really exists, please advise.  Otherwise, I've got some
> classes that I could contribute that would bridge that gap.
>

If we remove the toLowerCase() from the result set dyna bean classes, the
exact same code will run correctly on one database but not on another
(even if the schema is set up identically), depending on how the database
JDBC driver treats mixed case column names.  That's not acceptable for a
general purpose component like commons-beanutils.

JavaBeans already provides a solution to that problem for standard beans.
If the destination is DynaBeans based, it's pretty trivial to provide your
own mapping functions that do pretty much the same thing.

> Thanks!
> Ken Fitzpatrick

Craig