commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <>
Subject Re: [DbUtils]Making the BeanHandler... Even Smarter
Date Mon, 01 Dec 2003 19:03:41 GMT

----- Original Message -----
From: "Corby Page" <>
To: <>
Sent: Monday, December 01, 2003 8:32 PM
Subject: Re: [DbUtils]Making the BeanHandler... Even Smarter

> 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
> 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
> columns from the table. My DAO's frequently retrieve subsets of the
> 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.

I agree, It is not the best way to map resultsets too beans (I is simple
It must not be a problem to make  "mapColumnsToProperties()" protected
It is possible to add more protected methods for flexiblity like

> 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:
> For additional commands, e-mail:

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

View raw message