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 16:46:28 GMT

We can add handlers,converters, tools to "contributed" directory,  feature
will be moved
to "src" if community will find it usefull, DbUtils can become a "framework"
this way,  it is
not a major problem if community needs it, but new dependancies are.
I propose to discuss about repository in DbUtils for dependacy free
"contributed" code.
There are some ideas:

1. Type convertes. ( patch in bugzila )
2. Substitutions:
  SELECT *
  FROM MY_TABLE
  WHERE ${current_date} = field_0 AND
              ( field_1 like $1 OR field_2 like $1 OR field_3 like $1 ) AND
              (  field_4 = $2.beanPropValue  )

 I can forke it back from voruta.

3. Field name to bean property mapping (almost the same as 2, but not so
exotic ).



----- Original Message -----
From: "David Graham" <grahamdavid1980@yahoo.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, December 01, 2003 8:18 AM
Subject: Re: [DbUtils]Making the BeanHandler... Even Smarter


> One goal of DbUtils is to not become a "framework".  IMO, this feature is
> creeping towards framework status.  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.
>
>
> It's trivial to setup your queries so that you only have to write the
> SELECT part once if that's a big deal:
>
> Queries.properties
> ------------------
> query1.select=SELECT fname AS firstName, lname AS lastName
> query1.everythingElse=FROM person WHERE id=?
> query2.everythingElse=FROM person ORDER BY fname
>
> Java method
> --------------
> String sql = q.getString("query1.select") +
> q.getString("query2.everythingElse");
> run.query(sql, ...
>
> David
>
>
> --- Corby Page <CPage1@duke-energy.com> wrote:
> > I am finding that my DAOs that use the BeanHandler are ending up with a
> > lot
> > of code like this:
> >
> > String queryName = "select column1 as beanProp1, column2 as beanProp2,
> > column3 as beanProp3...."
> >
> > This gets to be very redundant and clunky for large rows, and it happens
> > because DbUtils assumes that the column name selected from your query
> > will
> > be an exact match for the exposed property of your JavaBean.
> >
> > What I would like to do is define a Map once in my DAO:
> >
> > Map columnMap = new HashMap();
> > columnMap.add( "column1", "beanProp1" );
> > columnMap.add( "column2", "beanProp2" );
> > ...
> >
> > and then I would like a way to tell DbUtils to override the default name
> > mappings of columns to properties by using the map I supply.
> >
> > I have two proposals for how I can accomplish this:
> >
> > 1) I can create an additional constructor for BasicRowProcessor that
> > takes
> > a nameMap as input. Then I would change the mapColumnsToProperties()
> > method
> > to check for the existence of such a map when performing the name
> > mapping.
> >
> > 2) Looking at proposal 1, it occurs to me that mapColumnsToProperties is
> > really more of a ColumnProcessor thing than a RowProcessor thing. I
> > could
> > refactor so that the BasicRowProcessor delegates to its ColumnProcessor
> > to
> > provide the mapColumnsToProperties functionality. Now, the nameMap would
> > be
> > passed into the BasicColumnProcessor class. Also, I would have to change
> > the method signature for the ColumnProcessor interface so that the
> > process
> > method takes a colunm name rather than an index number for its second
> > argument.
> >
> > If folks are agreeable to either of these two proposals, I am willing to
> > submit patch and testcase.
> >
> > Thanks,
> > 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
>


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