[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-db-sig
Subject:    [DB-SIG] DBAPI-2.0 clarifications
From:       mal () lemburg ! com (M ! -A !  Lemburg)
Date:       2001-03-19 16:30:43
Message-ID: 3AB63432.F0ACAAC7 () lemburg ! com
[Download RAW message or body]

brian zimmer wrote:
> 
> > > 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?

Right. My mistake.

> > 
> 
> 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.

No, .executemany() is needed to be clear about sequence of sequences...
strings are sequences too and these would cause very strangs effects
if used with .execute().
 
> > > 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.

Good :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/


[prev in list] [next in list] [prev in thread] [next in thread]