executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions)

Dittmar, Daniel daniel.dittmar@sap.com
Tue, 20 Mar 2001 11:46:16 +0100


> i better like  a clear api that puts some burden on the driver's 
> implementor but free the user/programmer from problems when switching 
> from a driver to another one. a won't call helping the final user a
> "waste of time."

I think this is true only when the choosen standard is based on experience.
Until then, I prefer
- to document the behaviour as implementation defined
- provide example code to achieve either behaviour which helps to gain
experience
- if after some time a consensus arises about the 'right' behaviour, then it
can be put into the standard

> a won't call helping the final user a
> "waste of time."

OK, change this to "relative waste of time because it is an exotic feature".
There are other areas where users would profit from more standardization
(different SQL dialects, BLOB handling), but where such a standardization
could be achieved only through large efforts by the driver implementor at
the possible cost of hiding the strength of the underlying database.

But you can ignore all of the above if we can find a solution 
- which can be easily implemented by all drivers
- which seems to be the 'right thing'
- which doesn't hide the strength of some database implementations

In this case (executemany of a SELECT), I see three possible alternatives
a) multiple result sets, where each result sets matches to exactly one set
of input parameters
b) exactly one result set, which is the union of the SELECTs
c) an undefined number of result sets with identical structure, where there
is no defined relation between each result set and a specific set of input
parameters

I would strongly oppose a)
- this kind of loop should be in application code
- hides the array SELECT of SAP DB (and probably Oracle, ...)

b) would be the most natural for SAP DB (well, after I implemented array
commands), but it would require additional work by drivers who don't supply
array commands

c) seems to be a solution everybody could live with
- databases supporting array commands create exactly one result set
- databases without array commands would implement .nextset () by executing
the next set of input parameters
- but maybe: client code is more cumbersome because of the explicit .nextset
() required

Daniel

--
Daniel Dittmar
daniel.dittmar@sap.com
SAP DB, SAP Labs Berlin
http://www.sapdb.org/