[DB-SIG] API Enhancements

[Tod Olson]

>>>>> "Greg" == Greg Stein <gstein@lyra.org> writes:

Greg> Oh... a question about the nextresult() method. Why is that
Greg> exposed?  Shouldn't the module just automatically move to the
Greg> next result set inside the fetch* methods? I don't see the
Greg> benefit of exposing that to the user. It seems an artifact of
Greg> the underlying database interface, rather than a useful
Greg> user-level concept.

[I assume you mean the nextset() method, else ignore me.]

The module should not just automatically move to the next result set
inside the fetch* methods.  The next result set could look very
different or need to be interpreted differently.  Take output from
Sybase's sp_helpdb as a trivial example (as displayed by isql or
sqsh, my ellipse):

     name     db_size       owner   dbid    created         status        
     -------- ------------- ------- ------  --------------  --------------
     horizon     31958.0 MB sa           5  May 10, 1998    no options set

    (1 row affected)
     device_fragments   size       usage       free kbytes
     ------------------ ---------- ----------- -----------
     sybdata1           1999.0 MB  data only        123840
     sybdata2           1990.0 MB  data only         26496
     sybdata3           1990.0 MB  data only         59984
     [...]	    	     	  
     syblog1            1999.0 MB  log only        1967440

    (return status = 0)


The user needs an indication when a result set is done, which is
currently provided by the fetch* methods returning None or [].  The
program signalling it's ready for the next result set by calling
nextset() is analogous to calling fetchone() for the next row: the
program is interested in a new, meaningful chunk of data.

Silently moving to the next result set means that a programmer would
have to do some kind of control break processing on each row's
description, in the case of fetchone(), in order to figure out when
the result set changed.  I don't even want to conjecture how
fetchmany() or fetchall() would or could behave in this context.

A pleasant side-effect of nextset() is that the programmer can skip
all or part of a result set without having to retrieve the whole
thing.  (Well, this *may* vary across database vendors who support
multiple result sets, but I'd be surprised.)

Tod A. Olson                        "How do you know I'm mad?" said Alice.
ta-olson@uchicago.edu               "If you weren't mad, you wouldn't have
The University of Chicago Library    come here," said the Cat.