Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <20031202034615.77729.qmail@web20704.mail.yahoo.com>
Date: Mon, 1 Dec 2003 19:46:15 -0800 (PST)
From: David Graham <grahamdavid1980@yahoo.com>
Subject: Re: [DbUtils]Making the BeanHandler... Even Smarter
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: 
 <OF4124718C.4E99BC8E-ON86256DEF.0063A48F-86256DEF.0065936D@duke-energy.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- Corby Page <CPage1@duke-energy.com> wrote:
> 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.

The mapColumnsToProperties() method *does* make sense as a private method.
 The member scopes in DbUtils were chosen deliberately, not randomly. 
They are private to avoid exposing implementation details to subclasses
which make it harder to change the implementation later.  The whole point
of defining a RowProcessor interface was to allow people to implement
whatever special features they needed without having to customize our
simple default
BasicRowProcessor implementation.

I'm not entirely opposed to making mapColumnsToProperties() protected but
I strongly disagree with making other methods like newInstance()
protected.  DbUtils isn't in the business of providing general Java helper
methods related to non-database topics like reflection.  If there's a need
for a newInstance() type of method it belongs in a different commons
component.

Would changing mapColumnsToProperties() to protected allow you to fully
implement your request?  Is representing the mapping as an int[] the best
way of doing things?  Is there a better name for the method?

David

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


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

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