springframework-developer

[Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

I was talking to Mark last weekend about data access for Spring.NET  
and we discussed the .NET class SqlCommand that provides a nice and  
clean interface to the ADO.NET functionality.  It got me thinking,  
and after adding the support for named parameters, I counted over 75  
different methods for interfacing with the JdbcTemplate - that's a  
lot :)

So, I started looking at providing a SqlCommand interface on top of  
JdbcTemplate to just present the most used features and limit the  
sometimes bewildering number of options for how to pass in the  
parameters etc.  I decided to only support the new named parameter  
support.  The old position based array style is still available from  
the JdbcTemplate directly.  I added a new class  
org.springframework.jdbc.command.SqlCommand to the sandbox.  It's  
simply a number of one-line wrappers on top of the JdbcTemplate.   
Combined with the new named parameter support, it provides a simpler  
interface IMHO.

Here are a few examples:

         SqlCommand listOfBeersCommand = new SqlCommand("select id,  
brand, price from beers", dataSource);
         List beerList = listOfBeersCommand.executeQuery(new  
BeerMapper());

         SqlCommand priceCommand = new SqlCommand("select price from  
beers where brand = :brand", dataSource);
         Map parameters = new HashMap();
         parameters.put("brand", "Heineken");
         Number price = (Number)priceCommand.executeScalar(parameters);

Also, with the new option of passing in a JavaBean as the holder of  
the parameter values (SqlParameterBeanWrapper) it does provide the  
option of using the following code:

         SqlCommand readCommand = new SqlCommand("select id, brand,  
price from beers where id = :id", dataSource);
         SqlCommand saveCommand = new SqlCommand("update beers set  
brand = :brand, price = :price where id = :id", dataSource);

         Map parameters = new HashMap();
         parameters.put("id", new Long(2));
         Beer beer = (Beer)readCommand.executeObject(new BeerMapper 
(), parameters);

         beer.setPrice(new BigDecimal("49.87"));

         SqlNamedParameters updateValues = new SqlParameterBeanWrapper 
(beer);
         int updateCount = saveCommand.executeUpdate(updateValues);

All this is in CVS now (SqlCommand is in the sandbox) and if you have  
any feedback, I'm all ears.

Thomas

Re: [Springframework-developer] New JDBC functionality for 1.3

[Juergen H. <ju...@in...>]

Thomas,

Looks interesting! Isn't this quite similar to our current operation objects
in the "jdbc.object" package, just more generic? A SqlCommand instance seems
to be thread-safe, parameters passed in through execute calls...

In any case, I do see your point: I guess it's worth keeping the named
parameter support restricted to such a command class, not in JdbcTemplate
itself. If that command class is close enough to the existing operation
objects in style, we could also put it into the "jdbc.object" package
directly...

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Saturday, November 19, 2005 5:50 PM
To: spr...@li...
Subject: [Springframework-developer] New JDBC functionality for 1.3

I was talking to Mark last weekend about data access for Spring.NET and we
discussed the .NET class SqlCommand that provides a nice and clean interface
to the ADO.NET functionality.  It got me thinking, and after adding the
support for named parameters, I counted over 75 different methods for
interfacing with the JdbcTemplate - that's a lot :)

So, I started looking at providing a SqlCommand interface on top of
JdbcTemplate to just present the most used features and limit the sometimes
bewildering number of options for how to pass in the parameters etc.  I
decided to only support the new named parameter support.  The old position
based array style is still available from the JdbcTemplate directly.  I
added a new class org.springframework.jdbc.command.SqlCommand to the
sandbox.  It's  
simply a number of one-line wrappers on top of the JdbcTemplate.   
Combined with the new named parameter support, it provides a simpler
interface IMHO.

Here are a few examples:

         SqlCommand listOfBeersCommand = new SqlCommand("select id, brand,
price from beers", dataSource);
         List beerList = listOfBeersCommand.executeQuery(new
BeerMapper());

         SqlCommand priceCommand = new SqlCommand("select price from beers
where brand = :brand", dataSource);
         Map parameters = new HashMap();
         parameters.put("brand", "Heineken");
         Number price = (Number)priceCommand.executeScalar(parameters);

Also, with the new option of passing in a JavaBean as the holder of the
parameter values (SqlParameterBeanWrapper) it does provide the option of
using the following code:

         SqlCommand readCommand = new SqlCommand("select id, brand, price
from beers where id = :id", dataSource);
         SqlCommand saveCommand = new SqlCommand("update beers set brand =
:brand, price = :price where id = :id", dataSource);

         Map parameters = new HashMap();
         parameters.put("id", new Long(2));
         Beer beer = (Beer)readCommand.executeObject(new BeerMapper (),
parameters);

         beer.setPrice(new BigDecimal("49.87"));

         SqlNamedParameters updateValues = new SqlParameterBeanWrapper
(beer);
         int updateCount = saveCommand.executeUpdate(updateValues);

All this is in CVS now (SqlCommand is in the sandbox) and if you have any
feedback, I'm all ears.

Thomas



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

Juergen,

For the moment the named parameter support is part of the  
JdbcTemplate, but we could move it to the SqlCommand class.  That  
would eliminate 11 methods from the JdbcTemplate.  Another question  
is if we provide the option of supporting named parameters in the  
classes that are part of the "object" package.  They already support  
naming the parameters in the parameter declaration but we could add  
support for using the name instead of the placeholder '?' in the sql  
itself.  This would eliminate the need for specifying the parameters  
in the correct order since we could associate them by name.

If we add the SqlCommand then I would consider the "object" package  
more or less deprecated and the new "command" style would be the way  
to go for the future.  We could provide SqlBatchCommand and  
SqlCallableCommand to provide everything that is currently provided  
in the "object" package.

The batch support needs some work anyway.  We are currently building  
up all the parameter values internally and then calling addBatch on  
the jdbc prepared statement which in turn build some memory structure  
to hold the parameters before the entire batch is executed later.   
This leads to some additional memory and cpu usage which is a problem  
dealing with large batches.

Thomas

On Nov 19, 2005, at 12:02 PM, Juergen Hoeller wrote:

> Thomas,
>
> Looks interesting! Isn't this quite similar to our current  
> operation objects
> in the "jdbc.object" package, just more generic? A SqlCommand  
> instance seems
> to be thread-safe, parameters passed in through execute calls...
>
> In any case, I do see your point: I guess it's worth keeping the named
> parameter support restricted to such a command class, not in  
> JdbcTemplate
> itself. If that command class is close enough to the existing  
> operation
> objects in style, we could also put it into the "jdbc.object" package
> directly...
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On  
> Behalf Of
> Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
>
> I was talking to Mark last weekend about data access for Spring.NET  
> and we
> discussed the .NET class SqlCommand that provides a nice and clean  
> interface
> to the ADO.NET functionality.  It got me thinking, and after adding  
> the
> support for named parameters, I counted over 75 different methods for
> interfacing with the JdbcTemplate - that's a lot :)
>
> So, I started looking at providing a SqlCommand interface on top of
> JdbcTemplate to just present the most used features and limit the  
> sometimes
> bewildering number of options for how to pass in the parameters  
> etc.  I
> decided to only support the new named parameter support.  The old  
> position
> based array style is still available from the JdbcTemplate  
> directly.  I
> added a new class org.springframework.jdbc.command.SqlCommand to the
> sandbox.  It's
> simply a number of one-line wrappers on top of the JdbcTemplate.
> Combined with the new named parameter support, it provides a simpler
> interface IMHO.
>
> Here are a few examples:
>
>          SqlCommand listOfBeersCommand = new SqlCommand("select id,  
> brand,
> price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
>
>          SqlCommand priceCommand = new SqlCommand("select price  
> from beers
> where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar 
> (parameters);
>
> Also, with the new option of passing in a JavaBean as the holder of  
> the
> parameter values (SqlParameterBeanWrapper) it does provide the  
> option of
> using the following code:
>
>          SqlCommand readCommand = new SqlCommand("select id, brand,  
> price
> from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set  
> brand =
> :brand, price = :price where id = :id", dataSource);
>
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper  
> (),
> parameters);
>
>          beer.setPrice(new BigDecimal("49.87"));
>
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
>
> All this is in CVS now (SqlCommand is in the sandbox) and if you  
> have any
> feedback, I'm all ears.
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam for All
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] New JDBC functionality for 1.3

[Juergen H. <ju...@in...>]

Thomas,

I'm wondering whether the named parameter support is really a candidate for
JdbcTemplate itself, due to the latter's one-line operation style that
doesn't really fit the named parameter building so well. And as you
indicated, JdbcTemplate has so many overloaded methods already...

I rather see the named parameter support as a thin level above JdbcTemplate,
with an API explicitly dedicated to named parameter handling. A command or
builder style API seems to be a good match here.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Saturday, November 19, 2005 8:19 PM
To: spr...@li...
Subject: Re: [Springframework-developer] New JDBC functionality for 1.3

Juergen,

For the moment the named parameter support is part of the JdbcTemplate, but
we could move it to the SqlCommand class.  That would eliminate 11 methods
from the JdbcTemplate.  Another question is if we provide the option of
supporting named parameters in the classes that are part of the "object"
package.  They already support naming the parameters in the parameter
declaration but we could add support for using the name instead of the
placeholder '?' in the sql itself.  This would eliminate the need for
specifying the parameters in the correct order since we could associate them
by name.

If we add the SqlCommand then I would consider the "object" package more or
less deprecated and the new "command" style would be the way to go for the
future.  We could provide SqlBatchCommand and SqlCallableCommand to provide
everything that is currently provided in the "object" package.

The batch support needs some work anyway.  We are currently building up all
the parameter values internally and then calling addBatch on the jdbc
prepared statement which in turn build some memory structure  
to hold the parameters before the entire batch is executed later.   
This leads to some additional memory and cpu usage which is a problem
dealing with large batches.

Thomas

On Nov 19, 2005, at 12:02 PM, Juergen Hoeller wrote:

> Thomas,
>
> Looks interesting! Isn't this quite similar to our current operation 
> objects in the "jdbc.object" package, just more generic? A SqlCommand 
> instance seems to be thread-safe, parameters passed in through execute 
> calls...
>
> In any case, I do see your point: I guess it's worth keeping the named 
> parameter support restricted to such a command class, not in 
> JdbcTemplate itself. If that command class is close enough to the 
> existing operation objects in style, we could also put it into the 
> "jdbc.object" package directly...
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
>
> I was talking to Mark last weekend about data access for Spring.NET 
> and we discussed the .NET class SqlCommand that provides a nice and 
> clean interface to the ADO.NET functionality.  It got me thinking, and 
> after adding the support for named parameters, I counted over 75 
> different methods for interfacing with the JdbcTemplate - that's a lot 
> :)
>
> So, I started looking at providing a SqlCommand interface on top of 
> JdbcTemplate to just present the most used features and limit the 
> sometimes bewildering number of options for how to pass in the 
> parameters etc.  I decided to only support the new named parameter 
> support.  The old position based array style is still available from 
> the JdbcTemplate directly.  I added a new class 
> org.springframework.jdbc.command.SqlCommand to the sandbox.  It's 
> simply a number of one-line wrappers on top of the JdbcTemplate.
> Combined with the new named parameter support, it provides a simpler 
> interface IMHO.
>
> Here are a few examples:
>
>          SqlCommand listOfBeersCommand = new SqlCommand("select id, 
> brand, price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
>
>          SqlCommand priceCommand = new SqlCommand("select price from 
> beers where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar
> (parameters);
>
> Also, with the new option of passing in a JavaBean as the holder of 
> the parameter values (SqlParameterBeanWrapper) it does provide the 
> option of using the following code:
>
>          SqlCommand readCommand = new SqlCommand("select id, brand, 
> price from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set 
> brand = :brand, price = :price where id = :id", dataSource);
>
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper 
> (), parameters);
>
>          beer.setPrice(new BigDecimal("49.87"));
>
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper 
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
>
> All this is in CVS now (SqlCommand is in the sandbox) and if you have 
> any feedback, I'm all ears.
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today 
> Register for a JBoss Training Course.  Free Certification Exam for All 
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today 
> Register for a JBoss Training Course.  Free Certification Exam for All 
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New JDBC functionality for 1.3

[Alef A. <ale...@in...>]

Isn't this just like introducing a 'lite' version of the JdbcTemplate 
(without exposing the actual template pattern) in order to keep things 
clean and simple for users? I agree there's a lot of methods on the 
JdbcTemplate, but every time I take about 5 minutes to explain the 
interface, users seem to grasp the API quite quickly... If the 
SqlCommand were around already I had to explain users two classes to 
interact instead of one.

About the SqlCommand class (it's a class), I don't exactly call this a 
nice and clean interface by the way, isn't it specific to SQLServer?? :-).

regards,
Alef

Juergen Hoeller wrote:
> Thomas,
> 
> Looks interesting! Isn't this quite similar to our current operation objects
> in the "jdbc.object" package, just more generic? A SqlCommand instance seems
> to be thread-safe, parameters passed in through execute calls...
> 
> In any case, I do see your point: I guess it's worth keeping the named
> parameter support restricted to such a command class, not in JdbcTemplate
> itself. If that command class is close enough to the existing operation
> objects in style, we could also put it into the "jdbc.object" package
> directly...
> 
> Juergen
>  
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Thomas Risberg
> Sent: Saturday, November 19, 2005 5:50 PM
> To: spr...@li...
> Subject: [Springframework-developer] New JDBC functionality for 1.3
> 
> I was talking to Mark last weekend about data access for Spring.NET and we
> discussed the .NET class SqlCommand that provides a nice and clean interface
> to the ADO.NET functionality.  It got me thinking, and after adding the
> support for named parameters, I counted over 75 different methods for
> interfacing with the JdbcTemplate - that's a lot :)
> 
> So, I started looking at providing a SqlCommand interface on top of
> JdbcTemplate to just present the most used features and limit the sometimes
> bewildering number of options for how to pass in the parameters etc.  I
> decided to only support the new named parameter support.  The old position
> based array style is still available from the JdbcTemplate directly.  I
> added a new class org.springframework.jdbc.command.SqlCommand to the
> sandbox.  It's  
> simply a number of one-line wrappers on top of the JdbcTemplate.   
> Combined with the new named parameter support, it provides a simpler
> interface IMHO.
> 
> Here are a few examples:
> 
>          SqlCommand listOfBeersCommand = new SqlCommand("select id, brand,
> price from beers", dataSource);
>          List beerList = listOfBeersCommand.executeQuery(new
> BeerMapper());
> 
>          SqlCommand priceCommand = new SqlCommand("select price from beers
> where brand = :brand", dataSource);
>          Map parameters = new HashMap();
>          parameters.put("brand", "Heineken");
>          Number price = (Number)priceCommand.executeScalar(parameters);
> 
> Also, with the new option of passing in a JavaBean as the holder of the
> parameter values (SqlParameterBeanWrapper) it does provide the option of
> using the following code:
> 
>          SqlCommand readCommand = new SqlCommand("select id, brand, price
> from beers where id = :id", dataSource);
>          SqlCommand saveCommand = new SqlCommand("update beers set brand =
> :brand, price = :price where id = :id", dataSource);
> 
>          Map parameters = new HashMap();
>          parameters.put("id", new Long(2));
>          Beer beer = (Beer)readCommand.executeObject(new BeerMapper (),
> parameters);
> 
>          beer.setPrice(new BigDecimal("49.87"));
> 
>          SqlNamedParameters updateValues = new SqlParameterBeanWrapper
> (beer);
>          int updateCount = saveCommand.executeUpdate(updateValues);
> 
> All this is in CVS now (SqlCommand is in the sandbox) and if you have any
> feedback, I'm all ears.
> 
> Thomas
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam for All
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New JDBC functionality for 1.3

[Thomas R. <tho...@tr...>]

Alef,

We already have two APIs - JdbcTemplate and the classes in the  
"object" package.  The new SqlCommand would more ore less replace the  
"object" classes.  As for the .NET version of the SqlCommand - I'm  
not a .NET expert and I haven't really used this class in any real  
app, but I thought the basic idea and API was pretty clean and looked  
easy to grasp and use..

I'm starting to lean more towards Juergens idea of having the named  
parameter support separate from the JdbcTemplate and apply the  
transformation to positional parameters done in the command layer.   
That way we could specify the SqlType information directly on the  
command object rather than with the parameters passed in.

Thomas


On Nov 19, 2005, at 5:12 PM, Alef Arendsen wrote:

> Isn't this just like introducing a 'lite' version of the  
> JdbcTemplate (without exposing the actual template pattern) in  
> order to keep things clean and simple for users? I agree there's a  
> lot of methods on the JdbcTemplate, but every time I take about 5  
> minutes to explain the interface, users seem to grasp the API quite  
> quickly... If the SqlCommand were around already I had to explain  
> users two classes to interact instead of one.
>
> About the SqlCommand class (it's a class), I don't exactly call  
> this a nice and clean interface by the way, isn't it specific to  
> SQLServer?? :-).
>
> regards,
> Alef
>
> Juergen Hoeller wrote:
>> Thomas,
>> Looks interesting! Isn't this quite similar to our current  
>> operation objects
>> in the "jdbc.object" package, just more generic? A SqlCommand  
>> instance seems
>> to be thread-safe, parameters passed in through execute calls...
>> In any case, I do see your point: I guess it's worth keeping the  
>> named
>> parameter support restricted to such a command class, not in  
>> JdbcTemplate
>> itself. If that command class is close enough to the existing  
>> operation
>> objects in style, we could also put it into the "jdbc.object" package
>> directly...
>> Juergen
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On  
>> Behalf Of
>> Thomas Risberg
>> Sent: Saturday, November 19, 2005 5:50 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] New JDBC functionality for 1.3
>> I was talking to Mark last weekend about data access for  
>> Spring.NET and we
>> discussed the .NET class SqlCommand that provides a nice and clean  
>> interface
>> to the ADO.NET functionality.  It got me thinking, and after  
>> adding the
>> support for named parameters, I counted over 75 different methods for
>> interfacing with the JdbcTemplate - that's a lot :)
>> So, I started looking at providing a SqlCommand interface on top of
>> JdbcTemplate to just present the most used features and limit the  
>> sometimes
>> bewildering number of options for how to pass in the parameters  
>> etc.  I
>> decided to only support the new named parameter support.  The old  
>> position
>> based array style is still available from the JdbcTemplate  
>> directly.  I
>> added a new class org.springframework.jdbc.command.SqlCommand to the
>> sandbox.  It's  simply a number of one-line wrappers on top of the  
>> JdbcTemplate.   Combined with the new named parameter support, it  
>> provides a simpler
>> interface IMHO.
>> Here are a few examples:
>>          SqlCommand listOfBeersCommand = new SqlCommand("select  
>> id, brand,
>> price from beers", dataSource);
>>          List beerList = listOfBeersCommand.executeQuery(new
>> BeerMapper());
>>          SqlCommand priceCommand = new SqlCommand("select price  
>> from beers
>> where brand = :brand", dataSource);
>>          Map parameters = new HashMap();
>>          parameters.put("brand", "Heineken");
>>          Number price = (Number)priceCommand.executeScalar 
>> (parameters);
>> Also, with the new option of passing in a JavaBean as the holder  
>> of the
>> parameter values (SqlParameterBeanWrapper) it does provide the  
>> option of
>> using the following code:
>>          SqlCommand readCommand = new SqlCommand("select id,  
>> brand, price
>> from beers where id = :id", dataSource);
>>          SqlCommand saveCommand = new SqlCommand("update beers set  
>> brand =
>> :brand, price = :price where id = :id", dataSource);
>>          Map parameters = new HashMap();
>>          parameters.put("id", new Long(2));
>>          Beer beer = (Beer)readCommand.executeObject(new  
>> BeerMapper (),
>> parameters);
>>          beer.setPrice(new BigDecimal("49.87"));
>>          SqlNamedParameters updateValues = new  
>> SqlParameterBeanWrapper
>> (beer);
>>          int updateCount = saveCommand.executeUpdate(updateValues);
>> All this is in CVS now (SqlCommand is in the sandbox) and if you  
>> have any
>> feedback, I'm all ears.
>> Thomas
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
>> Register for a JBoss Training Course.  Free Certification Exam for  
>> All
>> Training Attendees Through End of 2005. For more info visit:
>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
>> Register for a JBoss Training Course.  Free Certification Exam
>> for All Training Attendees Through End of 2005. For more info visit:
>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>