[dbutils] Setting bean properties fails silently

• Key: DBUTILS-3
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Tim Bailen
• Fix Version/s: 1.1

Environment

Operating System: other
Platform: Other

Description

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.

Comments

[Emmanuel Bourg]

The javadoc for the method BeanProcessor.toBean() states:

"The column type can be converted to the property's set method parameter type
with a ResultSet.get* method. If the conversion fails (ie. the property was an
int and the column was a Timestamp) an SQLException is thrown."

So I guess the right behavior in the case you mention would be to throw an
exception.

An alternative would be to try a conversion (long->int) and cast an exception
only if it's not possible (because the value overflows).

[Alan B. Canon]

The above described behaviour of BeanProcessor.toBean() can be fixed by changing the implementation to the following:

private void callSetter(Object target, PropertyDescriptor prop, Object value)
throws SQLException {

Method setter = prop.getWriteMethod();

if (setter == null) { return; }

Class[] params = setter.getParameterTypes();
try {
// Don't call setter if the value object isn't the right type
if (this.isCompatibleType(value, params[0])) {
setter.invoke(target, new Object[] { value });
} else { throw new SQLException( "Cannot set " + prop.getName() + ": incompatible types."); }

} catch (IllegalArgumentException e) { throw new SQLException( "Cannot set " + prop.getName() + ": " + e.getMessage()); } catch (IllegalAccessException e) { throw new SQLException( "Cannot set " + prop.getName() + ": " + e.getMessage()); } catch (InvocationTargetException e) { throw new SQLException( "Cannot set " + prop.getName() + ": " + e.getMessage()); }
}

[Henri Yandell]

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).

[Alan B. Canon]

Patch to resolve issue as described in previous comments.

[Alan B. Canon]

I supplied a patch for DBUTILS-1 which also fixes the present issue. It would be best to apply the patch for DBUTILS-1, and not the patch submitted above.

[Henri Yandell]

Oops, bad on my part. Your patch for DBUTILS-32 included this fix and I applied that part of it without noticing.

So this is resolved as a part of r470003.