commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corby Page" <CPa...@duke-energy.com>
Subject Re: [DbUtils]Making the BeanHandler... Even Smarter
Date Mon, 01 Dec 2003 18:32:12 GMT
Hmmm... I'm curious what the use case contexts are that people are using
DbUtils in. I'll give you mine:

I am working in an enterprise development environment where application
developers are far removed from the DBA's that maintain the legacy
databases. The database and table structures of these databases are more
complicated than what can be handled with O-R mapping tools like Hibernate
or CMP. So, I like using DbUtils in places where I need finer-grained
control over persistence mapping than what I can get from existing O-R
tools.

In my environment, it is untenable to assume that database columns are
always going to exactly match the datatype and name of their associated
JavaBean properties. So, offering some ability to customize this would be
an appealing feature of the library for me.

David and Juazos both suggested that I place the select cause in a property
or string to be shared by DAO's finders. But that relies on the simplistic
assumption that every single select method will want to retrieve all of the
columns from the table. My DAO's frequently retrieve subsets of the columns
that will actually be used by the query, reducing critical serialization
overhead by as much as 75%. I suppose the alternative would be to define a
separate named select string for each column set that is retrieved by a
finder, but that puts me right back where I started.

David writes: "IMO, this feature is creeping towards framework status."

Fine, then let's not implement the feature. But let's at least make the
library flexible enough so that people who want the feature can implement
it. Hiding mapColumnsToProperties() as a private method of
BasicRowProcessor makes no sense, and it basically forces me to rewrite
BasicRowProcessor, rather than extending it, if I want to change the
behavior. In turn, this will make migration to later versions of DbUtils
more painful for me.

David writes: "Using an SQL 'AS' is simpler and clearer than writing Java
code which forces you to maintain information about your queries in two
separate places, needlessly complicating things."

I am using DbUtils in a large enterprise application, and the reason I
brought this up is because it is getting to the point where it is not
simpler or clearer. I think it makes sense to give users the option of
which approach they would like to take.

Anyway, I wanted to make my points and I'm happy to offer up patches to
implement any of these suggestions. Thanks again to the authors of a very
useful framework... err, library.  :)

Corby



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message