commons-dev mailing list archives

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

----- Original Message -----
From: "Corby Page" <CPage1@duke-energy.com>
To: <commons-dev@jakarta.apache.org>
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
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.

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

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


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