[ 
http://issues.apache.org/jira/browse/DBUTILS-3?page=comments#action_12446005 ] 
            
Henri Yandell commented on DBUTILS-3:
-------------------------------------

Any chance of a patch file? Will make it easier if you're in the habit of 
supplying those sooner rather than later.

'svn diff' can create them, as can the GUI svn tools (I presume).

> [dbutils] Setting bean properties fails silently
> ------------------------------------------------
>
>                 Key: DBUTILS-3
>                 URL: http://issues.apache.org/jira/browse/DBUTILS-3
>             Project: Commons DbUtils
>          Issue Type: Bug
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Tim Bailen
>             Fix For: 1.1
>
>
> 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.
> POSSIBLE RESOLUTIONS
> --------------------
> 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: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to