commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Culp <>
Subject [dbutils] mapping bean props to SQL IN parms
Date Thu, 19 Feb 2004 23:33:18 GMT
Hi, I have added simple bidirectional bean mapping into dbutils
using a mapper to map a bean props to the columns identified
in the SQL statement. 

To enable:

MappedQueryRunner run = new MappedQueryRunner();
run.update(connection, "INSERT into Customers (id, FirstName, 
MiddleInitial, LastName," +
           "Address, City, State, ZipCode) values (?,?,?,?,?,?,?,?)",
            customer, beanMap);

Initially, I added the behavior to QueryMapper by allowing
a bean and a collection of PropertyDescriptors to the query
and update() methods and added a private method getMappedParams()
to map the column names in the SQL to the bean getters and
create the object[] for fillStatement.

Since Im using the toBean() in the BasicRowProcessor it seemed to
make sense to be able to populate the statement on input using
the same map.

Is anyone interested in this and if so what would be the best

Here's my thoughts on the factoring -

One thing I noticed was that the ResultSetHandlers are very small classes
since they delegate to the RowProcessor to actually retrieve the result
sets values.  The BasicRowProcessor implementation seems to be growing
horizontally with the different types of returned objects from the 

When it comes to processing a bean the functionality seems to grow more 
that is not as simple an operation as toArray etc almost taking over 

There is already an ArrayHandler, a BeanHandler etc.  tied to each
correspondingly typed method in BasicRowProcessor. Why not roll the 
actual functionality
back into them the handlers themselves?

ColumnProcessor seems to only exist to support bean mapping as well.

I see possible entry points for input and output transformation
being ResultSetHandler.handle() <-- already there
and StatementHandler.handle() <--- statement handler doesnt exist.

This way the core DBUtil functionality should remain undisturbed by the 
different transformations of resultsets and the various input preprocessing
such as mapping bean props to the statement INs while supporting some 

Also, is it necessary to provide separate ResultSetHandlers for single row
return values and collections?  If one assumes a collection is always
the return, then its a simple matter to retrieve the first element
and cast it.

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

View raw message