commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan B. Canon (JIRA)" <>
Subject [jira] Updated: (DBUTILS-3) [dbutils] Setting bean properties fails silently
Date Wed, 01 Nov 2006 15:29:20 GMT
     [ ]

Alan B. Canon updated DBUTILS-3:

    Attachment: patch-DBUTILS-3.txt

Patch to resolve issue as described in previous comments.

> [dbutils] Setting bean properties fails silently
> ------------------------------------------------
>                 Key: DBUTILS-3
>                 URL:
>             Project: Commons DbUtils
>          Issue Type: Bug
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Tim Bailen
>             Fix For: 1.1
>         Attachments: patch-DBUTILS-3.txt
> I had a property in my bean that wasn't being set by BeanHandler. No matter 
> the value of the matching field name in the database, the value in the bean 
> would always come back as 0.
> I traced the culprit to BasicRowProcessor.callSetter(), which calls the  
> setter method on the bean corresponding to the same field name in the 
> database. Before it attempts to call the setter, it checks to make sure that 
> the type of the value retrieved from the database is compatible with the type 
> of the bean. This behavior is fair enough, but if the types are determined to 
> be incompatible, DBUtils essentially fails silently. That is, it does not call 
> the setter and it does nothing to inform the developer that this is what 
> happened.
> This was frustrating for me because I had a field that was type int in my bean 
> and type long in the database, but I didn't realize why it wasn't being set 
> until I stepped through the code.
> --------------------
> 1. Start a FAQ for DBUtils and mention that a bean's property will not be 
> initialized if its type is incompatible with the corresponding field in the 
> database
> 2. Log some message to this effect when it occurs (I don't believe DBUtils has 
> any logging, so this probably isn't viable)
> 3. Throw an exception when this case occurs. Better that the program fail 
> obviously and with some information about what happened rather than return a 
> bean in an invalid state.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message