--- Corby Page <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
