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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
