You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Corby Page <CP...@duke-energy.com> on 2003/12/01 03:01:27 UTC
[DbUtils]Making the BeanHandler... Even Smarter
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DbUtils]Making the BeanHandler... Even Smarter
Posted by Juozas Baliuka <ba...@centras.lt>.
You can do it with strings too:
private static String FIELD_LIST = " column1 as beanProp1, column2 as
beanProp2,
column3 as beanProp3.... ";
String sql1 = "SELECT" + FIELD_LIST + "FROM ... ";
I use this way:
"SELECT ${FIELD_LIST} FROM ... ";
I think it can be better to use this map for any dynamic sql:
Map context = new HashMap();
context.add( "var1", "function" );
context.add( "FIELD_LIST", FIELD_LIST );
"SELECT ${FIELD_LIST} FROM MY_TABLE WHERE ${function}(name) = $1 ";
> 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
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [DbUtils]Making the BeanHandler... Even Smarter
Posted by Juozas Baliuka <ba...@centras.lt>.
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" <gr...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@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 <CP...@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
Re: [DbUtils]Making the BeanHandler... Even Smarter
Posted by David Graham <gr...@yahoo.com>.
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 <CP...@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
RE: [DbUtils]Making the BeanHandler... Even Smarter
Posted by Steven Caswell <st...@mungoknotwise.com>.
I'm interested in the idea and would like to see the patch and test case.
One slight clarification to proposal 2, I think I'd prefer to overload the
existing method rather than change it, for backward compatibility.
Steven Caswell
Sun Certified Java Programmer
steve@mungoknotwise.com
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Corby Page [mailto:CPage1@duke-energy.com]
> Sent: Sunday, November 30, 2003 9:01 PM
> To: commons-dev@jakarta.apache.org
> Subject: [DbUtils]Making the BeanHandler... Even Smarter
>
>
> 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
>
>
>
> ---------------------------------------------------------------------
> 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