commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject Re: [DbUtils]Improving the BeanHandler
Date Tue, 25 Nov 2003 17:49:37 GMT

--- Corby Page <CPage1@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


Mime
View raw message