[DB-SIG] DBAPI-2.0 clarifications

[brian zimmer]

>
> hi,
>
> 	ok, i'll send you patches to the dbapi document to better clarify
> the "obscure points" (no offense intended to you as the editor ;). just
> a last comment, in your first answer to my original posting you said:
>
>   Multiple result sets refer to the output format and only comes
>   into play for stored procedure which may return multiple result
>   sets. .nextset() then switches to the next available result set.
>
> now, this is a little different from:
>
> > I think the docs on .nextset() are clear about this. .fetchXXX()
> > APIs only work on the current result set and a call .nextset()
> > advances to the next available result set.
>
> the first seems to imply that .nextset() does not apply to the results
> of an .executemany() but only to the result sets generated by a stored
> procedure called via .callproc(). your example below tells the opposite.
> can i take the example as the right thing and send you a patch to the
> dbapi document for this one too?
>
> > cursor.execute('select * from mytable where id = ?', [(1,), (2,)])
>          ^^^^^^^
> executemany(), right?
>

Why do we have an .executemany() when .execute() appears to solve the problem?  I also think it makes it easier on the end user
since they only have one method to use at any one time.  My .executemany() just invokes .execute() which figures out whether the
params are a sequence of sequences or not.

> > resultsets = []
> > while 1:
> >     resultsets.append(cursor.fetchall())
> >     if not cursor.nextset():
> >         break
> >
> > resultsets ... [[(1,'first')], [(2,'second')]]
>

This is precisely what I expected to see.

As for testing, I'd be greatly in favor of DB API 2.0-compliant test.  I think it would help tremendously.

thanks,

brian