[DB-SIG] Optional DB API Extensions

[Matthew T. Kromer]

brian zimmer wrote:

>What's the reasoning behind having .execute and .executemany?  In zxJDBC, I
>(apparently erroneously) allow .execute to behave like .executemany.  It
>doesn't affect anything functionally and minimizes the client requirement to
>check if you have multiple bound parameters, no?
>
>brian
>

There are a few reasons I can think of.

Firstly, execute() is pretty clearly intended to execute once only; so I 
would think that should the API be able to take an array bind, that 
argument lists or tuples in an execute() should be converted to an 
array.  In the executemany() form, lists would represent the range of 
values over which to execute (ie repeat the statement).

Secondly, what happens if you execute('select * from emp where empid = 
:1', ((10, 20, 30, 40)))?  Some implementations might generate a LIST of 
result sets, but there are cases where repeat execution as implicit 
behavior leads to undefined or unexpected results.

The multiple-execute behavor of execute() is sadly a vestige of API 1.0, 
something I dont like but am pretty much stuck with though.

I get just as put out trying to be overly-pythonic, ie where the 
signature of the method calls for one and only one parameter, so you 
have to pass in lists.  I would argue that

    cursor.execute("select * from emp where empid = :1 and mgrid = :2", 
10, 20)

is more readable than

    cursor.execute("select * from emp where empid = :1 and mgrid = :2", 
(10, 20))

And the latter is the API 2.0 form.  As an adapter author, I actually 
try to support both notations, largely out of personal preference, yet 
there are potential ambiguities.