[DB-SIG] DB-API 1.1

Greg Stein (Exchange) gstein@exchange.microsoft.com
Sun, 14 Jun 1998 20:07:49 -0700


> From: M.-A. Lemburg [mailto:mal@lemburg.com]
> Sent: Friday, June 05, 1998 1:54 AM
> 
> Tod Olson wrote:
> > 
> > >>>>> "M" == M -A Lemburg <mal@lemburg.com> writes:
> > 
> > M> Things to be considered obsolete:
> > M>      arraysize
> > M>      setinputsize()
> > M>      setoutputsize()
> > 
> > M>      Completely agree on punting these... fetchmany() would then
> > M>      have a mandatory argument instead of an optional one.
> > 
> > I actually found arraysize to be useful when I implemented array
> > binding in a module I was working on.  I could allocate the 
> space for
> > the array binding when the user set the variable and avoid doing a
> > malloc and free on every call to fetch*.  That is, it was a 
> nice hint
> > for handling memory in a place where Python couldn't help me.

This is exactly the reason for the introduction of these attributes /
methods.

> But arraysize is only intended as default argument for fetchmany()
> -- what if the user decides s/he only wants arraysize/2 or arraysize*2
> rows by passing an argument to fetchmany() ?
> 
> BTW: You can still optimize malloc/free's by reusing the arrays
> for every fetchmany()-call. Calling realloc normally isn't that
> costly.

Nope. No can do. You want the size *before* calling execute(). For the most
efficient array operation, you want to bind your input and output arrays,
then prepare the statement (the prepare is done inside execute()). Finally,
you start fetching results.

This high-performance capability is well within the realm of capability of a
Python module. The DB-API was designed with this high-perf possibility in
mind for future growth. The fact that people haven't yet built it does not
negate that the API is an appropriate design for DBAPI implementors to grow
into.

The fetchmany() has an argument only for the purpose of batching up a number
of results to return to a Python program. It usually cannot interact with
any array-binding possibilities. One of the pieces of input that I received
from the Dec 95 conference was that people wanted the fetchmany/fetchall
methods (fetchone was insufficient). The point was "usually you want them
all, anyhow." Practically speaking, though, fetchall() can get you in
trouble if the particular query happened to return all 200 megs of your
database. Therefore, the fetchmany() was introduced to effectively say "give
me all of them, but limit to 100 just in case."

-g