You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Corby Page <CP...@duke-energy.com> on 2003/11/25 18:18:00 UTC
[DbUtils]Improving the BeanHandler
Hi, first off I'd like to say thanks for the DbUtils package. It has been
very helpful for cleaning up my code in places where I have to do manual
persistence.
I have had to modify the code in order to use the BeanHandler, and I wanted
to offer my modifications as a patch to the codebase.
Let me run through a quick use-case: I have a bean with a property called
quantity of type double. I tried to populate this bean with a SELECT
statement using the BeanHandler.
However, the BasicRowProcessor.createBean( ... ) method executes the
following code:
Object value = rs.getObject(i);
The return type from my Sybase JDBC Driver here is BigDecimal. Since this
isn't a perfect match for the exposed bean property, it refuses to populate
the property.
When I code this persistence operation by hand, I use rs.getDouble(i). This
way, I make the vendor do the work for me. I tell the vendor I expect a
double return type, and he is responsible for performing the
BigDecimal.doubleValue() conversion.
So, I have created my own custom RowProcessor that replaces the getObject
call from above with a method that looks like this:
Object value;
if ( propType.equals( Double.TYPE ) || propType.equals(
Double.class ) )
{
value = new Double( rs.getDouble( index ) );
}
....
else
{
value = rs.getObject( index );
}
This is implemented for all of the appropriate ResultSet methods of course.
Now, we look at the type of the named property, and we call the appropriate
method of the JDBC driver to get the vendor to adapt to that type, if
possible. This feels a lot more flexible than requiring a bean property to
precisely match a (possibly arbitrary) default type used by the JDBC
vendor.
I would be happy to offer this code as a patch to BasicRowProcessor, as an
alternate RowProcessor that extends BasicRowProcessor, or leave it up to
you guys to implement if you feel this is a good idea.
Thanks,
Corby
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DbUtils]Improving the BeanHandler
Posted by Juozas Baliuka <ba...@centras.lt>.
"public Object getObject(int i,
Map map)
throws SQLException"
Doe's somebody tried to use this method ? I am not sure, but looks like it
can be driver specific.
It is trivial to implement converters. It can be something like this:
//delegates convertion for driver
Object getObject( ResultSet rs, int col, int jdbcType ){
switch(){
case Types.INT :
return new Integer(rs.getInt(col));
..................
}
}
and
int [] toJdbcTypes( PropertyDescriptors [] props ) {
int [] result = new int[propTypes.length];
for( int i= 0, len = propTypes.length; i < len; i++ ){
Integer type = (Integer)classToJdbcMap.get(props[i].getType());
if(type == null){
throw new Exception("register mapping for " + props[i].getType());
}
result[i] = type.intValue();
}
}
This kind of implementation must be performant.
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, November 25, 2003 7:49 PM
Subject: Re: [DbUtils]Improving the BeanHandler
>
> --- Corby Page <CP...@duke-energy.com> wrote:
> > Hi, first off I'd like to say thanks for the DbUtils package. It has
> > been
> > very helpful for cleaning up my code in places where I have to do manual
> > persistence.
> >
> > I have had to modify the code in order to use the BeanHandler, and I
> > wanted
> > to offer my modifications as a patch to the codebase.
> >
> > Let me run through a quick use-case: I have a bean with a property
> > called
> > quantity of type double. I tried to populate this bean with a SELECT
> > statement using the BeanHandler.
> >
> > However, the BasicRowProcessor.createBean( ... ) method executes the
> > following code:
> >
> > Object value = rs.getObject(i);
> >
> > The return type from my Sybase JDBC Driver here is BigDecimal. Since
> > this
> > isn't a perfect match for the exposed bean property, it refuses to
> > populate
> > the property.
> >
> > When I code this persistence operation by hand, I use rs.getDouble(i).
> > This
> > way, I make the vendor do the work for me. I tell the vendor I expect a
> > double return type, and he is responsible for performing the
> > BigDecimal.doubleValue() conversion.
> >
> > So, I have created my own custom RowProcessor that replaces the
> > getObject
> > call from above with a method that looks like this:
> >
> > Object value;
> > if ( propType.equals( Double.TYPE ) || propType.equals(
> > Double.class ) )
> > {
> > value = new Double( rs.getDouble( index ) );
> > }
> > ....
> > else
> > {
> > value = rs.getObject( index );
> > }
> >
> > This is implemented for all of the appropriate ResultSet methods of
> > course.
> > Now, we look at the type of the named property, and we call the
> > appropriate
> > method of the JDBC driver to get the vendor to adapt to that type, if
> > possible. This feels a lot more flexible than requiring a bean property
> > to
> > precisely match a (possibly arbitrary) default type used by the JDBC
> > vendor.
>
> The types returned by rs.getObject() are not arbitrary; they are
> explicitly defined in the JDBC specification. Your proposal certainly
> looks more flexible than the current implementation. At least we designed
> with interfaces to make your interim solution possible :-).
>
> >
> > I would be happy to offer this code as a patch to BasicRowProcessor, as
> > an
> > alternate RowProcessor that extends BasicRowProcessor, or leave it up to
> > you guys to implement if you feel this is a good idea.
>
> Please open an enhancement ticket with a patch to BasicRowProcessor and
> test cases attached. We can review it further after we see the exact code
> changes.
>
> David
>
> >
> > Thanks,
> > Corby
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DbUtils]Improving the BeanHandler
Posted by David Graham <gr...@yahoo.com>.
--- Corby Page <CP...@duke-energy.com> wrote:
> Hi, first off I'd like to say thanks for the DbUtils package. It has
> been
> very helpful for cleaning up my code in places where I have to do manual
> persistence.
>
> I have had to modify the code in order to use the BeanHandler, and I
> wanted
> to offer my modifications as a patch to the codebase.
>
> Let me run through a quick use-case: I have a bean with a property
> called
> quantity of type double. I tried to populate this bean with a SELECT
> statement using the BeanHandler.
>
> However, the BasicRowProcessor.createBean( ... ) method executes the
> following code:
>
> Object value = rs.getObject(i);
>
> The return type from my Sybase JDBC Driver here is BigDecimal. Since
> this
> isn't a perfect match for the exposed bean property, it refuses to
> populate
> the property.
>
> When I code this persistence operation by hand, I use rs.getDouble(i).
> This
> way, I make the vendor do the work for me. I tell the vendor I expect a
> double return type, and he is responsible for performing the
> BigDecimal.doubleValue() conversion.
>
> So, I have created my own custom RowProcessor that replaces the
> getObject
> call from above with a method that looks like this:
>
> Object value;
> if ( propType.equals( Double.TYPE ) || propType.equals(
> Double.class ) )
> {
> value = new Double( rs.getDouble( index ) );
> }
> ....
> else
> {
> value = rs.getObject( index );
> }
>
> This is implemented for all of the appropriate ResultSet methods of
> course.
> Now, we look at the type of the named property, and we call the
> appropriate
> method of the JDBC driver to get the vendor to adapt to that type, if
> possible. This feels a lot more flexible than requiring a bean property
> to
> precisely match a (possibly arbitrary) default type used by the JDBC
> vendor.
The types returned by rs.getObject() are not arbitrary; they are
explicitly defined in the JDBC specification. Your proposal certainly
looks more flexible than the current implementation. At least we designed
with interfaces to make your interim solution possible :-).
>
> I would be happy to offer this code as a patch to BasicRowProcessor, as
> an
> alternate RowProcessor that extends BasicRowProcessor, or leave it up to
> you guys to implement if you feel this is a good idea.
Please open an enhancement ticket with a patch to BasicRowProcessor and
test cases attached. We can review it further after we see the exact code
changes.
David
>
> Thanks,
> Corby
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org