[DB-SIG] API Enhancements

M.-A. Lemburg mal@lemburg.com
Wed, 03 Mar 1999 15:10:30 +0100

Bill Tutt wrote:
> > From: M.-A. Lemburg [mailto:mal@lemburg.com]
> >
> >
> > Greg Stein wrote:
> > > Oh... a question about the nextresult() method. Why is that exposed?
> > > Shouldn't the module just automatically move to the next result set
> > > inside the fetch* methods? I don't see the benefit of
> > exposing that to
> > > the user. It seems an artifact of the underlying database interface,
> > > rather than a useful user-level concept.
> >
> > As Tod already pointed out, the nextset() method does have its
> > use for stored procedures: result sets are needed to group data.
> > If the interface would just silently move to the next set, there
> > would be no way to identify the set boundary.
> >
> There's nothing preventing the spec from specifying something along the
> following:
> If there are multiple result sets:
>         At the end of the first result set, fetch*() returns None.
>         The next call to fetch*() will return the first row of the next
> resultset. (if any).

This would work with .fetchone(), but not with fetchmany() and
.fetchall() since the latter always return (possibly empty) sequences.

It would also make the needed code look a bit cumbersome; with
.nextset() you can write:

while 1:
	...fetch result set...
	if not cursor.nextset():

> The user definately needs to see a demarkation between the result sets as
> the different result sets typically have different row layouts.
> The prototypical example for doing things like this is returning 1:1
> information in the first result set, with the second result set containing
> N:N information sorted on the reference mode (PK or AK)of the first result
> set.

Marc-Andre Lemburg                               Y2000: 303 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :