ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clough, Samuel \(USPC.PRG.Atlanta\)" <Samuel_Clo...@princetonrg.com>
Subject RE: Statement Batching
Date Thu, 26 Apr 2007 12:41:24 GMT
I think I've mentioned this before but I forget if it was on the list or
not.  I agree that batch support should be included in iBatis in a
generic way.  For example, JDBC has generic batch options on prepared
statements.  If it's generic, the framework can then offer driver
specific implementations that can be hooked up via the provider file
like all the other classes ADO uses are.

-----Original Message-----
From: Ron Grabowski [mailto:rongrabowski@yahoo.com] 
Sent: Wednesday, April 25, 2007 11:19 PM
To: user-cs@ibatis.apache.org
Subject: Re: Statement Batching

There isn't any prohibiting you from using Ayende's example code with
IBatisNet now:

// his reflection sample...you could also use the delegate code
for (int i = 0; i < products.Count; i++)
 appendInfo.Invoke(sqlCmdSet, new object[] {
  SqlMapperAdapter.BuildDbCommand(sqlMapper, "Product.Update",

Its just a matter of asking IBatisNet for the IDbCommand it generates

public static IDbCommand BuildDbCommand(ISqlMapper sqlMapper, string
statement, object parameter)
// retrieve the specific <update>, <delete>, or <insert> statement
MappedStatement mappedStatement = (MappedStatement)

// instanciate a new IDbConnection and set its ConnectionString property
SqlMapSession session = new SqlMapSession(sqlMapper);

// set the CommandText and Connection property of an IDbCommand
RequestScope request =
parameterObject, session);

// fill the Parameters property of the IDbCommand
mappedStatement.PreparedCommand.Create(request, session,
mappedStatement.Statement, parameterObject);           

// DbCommandDecorator should expose its inner command as a property
FieldInfo fieldInfo =
BindingFlags.NonPublic | BindingFlags.Instance);
return (IDbCommand)fieldInfo.GetValue(request.IDbCommand);

A property needs to be added to one of the internal classes so the last
line is just:

return mappedStatement.PreparedCommand.InnerCommand;

Is the batching supported on Sql Server 2000? 

IBatisNet is focused on using the ADO.Net interfaces for data access. Is
it a good idea to make special cases for specific drivers and make calls
to non-public members?

Perhaps we could extend SqlMapper and create a BatchSqlMapper that
supports StartBatch() and ExecuteBatch() or modify
MappedStatement.ExecuteUpdate to accept an execution strategy that
chooses between ExecuteNonQuery or a custom stragey that relies on
calling the non-public members of SqlCommandSet.

----- Original Message ----

From: "Tan, Lee" <Lee.Tan@qg.com>

To: user-cs@ibatis.apache.org

Sent: Tuesday, April 24, 2007 2:55:21 PM

Subject: Statement Batching

      Has there been much  interest in implementing batching in iBatis?

 http://ayende.com/Blog/archive/2006/09/13/7276.aspx has some good
statistics on possible performance gains  accessing these included
batching methods via reflection and  delegates.

 We're looking at the same problems and right now the  prevailing winds
are pushing us to use iBatis only for Selects with all Updates, Inserts,
and Deletes being handled manually and I'd like to avoid that if


 Lee Tan  

Information  Systems - Software Development 


 Sussex,  Wisconsin 

414-566-6716 phone 

414-566-4010x6716 beeper  



Princeton Retirement Group, Inc - Important Terms 
This E-mail is not intended for distribution to, or use by, any person or entity in any location
where such distribution or use would be contrary to law or regulation, or which would subject
Princeton Retirement Group, Inc. or any affiliate to any registration requirement within such
This E-mail may contain privileged or confidential information or may otherwise be protected
by work product immunity or other legal rules. No confidentiality or privilege is waived or
lost by any mistransmission. Access, copying or re-use of information by non-intended or non-authorized
recipients is prohibited. If you are not an intended recipient of this E-mail, please notify
the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute
any portion of this E-mail. 
The transmission and content of this E-mail cannot be guaranteed to be secure or error-free.
Therefore, we cannot represent that the information in this E-mail is complete, accurate,
uncorrupted, timely or free of viruses, and Princeton Retirement Group, Inc. cannot accept
any liability for E-mails that have been altered in the course of delivery. Princeton Retirement
Group, Inc. reserves the right to monitor, review and retain all electronic communications,
including E-mail, traveling through its networks and systems (subject to and in accordance
with local laws). If any of your details are incorrect or if you no longer wish to receive
mailings such as this by E-mail please contact the sender by reply E-mail. 


View raw message