[DB-SIG] Cursor.executemany() and Cursor.nextset()
Dittmar, Daniel
daniel.dittmar@sap.com
Mon, 6 Aug 2001 14:20:00 +0200
> I can even imagine the justification for providing
> executemany() in the
> case of data manipulation queries (INSERT, UPDATE, DELETE),
> though it's
> not entirely clear to me that such batching isn't more appropriately
> handled by client code.
Some drivers can implement this more efficient than a simple loop could.
> So, if I were implementing the API, what should my code do if
> executemany() is invoked with multiple parameter sets on a stored
> procedure which returns multiple result sets? The choices I
There was a discussion about this topic a few weeks/months ago, with the
result being something like this:
- the semantics of executemany () with regard to SELECT/CALL are very
database specific. Writers of drivers are reluctant to hide specific
features of the underlying database.
- one possible solution was to allow multiple result sets, but not to
require them. Thus databases which allow batch SELECTs could create a single
result set, other databases would create one for each parameter set.
Portable client code would have to check for multiple result sets.
> It seems to me that the API is either overly ambitious or
> insufficiently
> specified (or both) in this area.
It is insufficiently specified, but for a reason. This should probably be
stated more clearly in the specification.
> I strongly recommend that the use of executemany for commands
> producing
> result sets be deprecated, and eventually forbidden (assuming
> the method
> is retained at all).
Depending on the database, there may be no possibility to check whether a
statement returns a result set short of executing it.
Daniel
--
Daniel Dittmar
daniel.dittmar@sap.com
SAP DB, SAP Labs Berlin
http://www.sapdb.org/