Re: Use generators instead of lists for resultsets?

[email protected] Tue, 28 Jun 2005 20:27:14 +0100
Newsgroups gmane.comp.web.skunkweb
Message-ID <[email protected]>
Hi Jacob

I agree that potential network latency probably makes it undesirable to switch
over completely to using 'fetchone' rather than 'fetchall', and so we will
probably need to have various fetching strategies. You expressed misgivings
about 'getSome' sometimes returning a generator and other times a list. Is
there any reason why it (and the functions it makes use of) can't always return
an iterator, even when 'fetchall' has been used? If this iterator [1] were to
implement a '__len__' method (returning the cursor's rowcount), then it would
be an almost seamless replacement for a list as far as other code was
concerned.

In the 'oracleconn' module I reimplemented 'execute' to use 'fetchone' [2]
rather than use 'fetchall'. But this wasn't so much motivated by an attempt to
reduce memory overhead; rather, Oracle's LOB locators get invalidated if you
don't use them before the next fetch (at least with cx_Oracle). But rather than
always use 'fetchone', it would be better if this was done only when wanted -
whether to reduce memory or because of the use of LOBs. This could be
controlled by an attribute of the associated table class.

So here's what I now propose:

1. Rewrite getSome and auxiliaries to return a ResultSet object that implements
iteration and __len__

2. Define a pydo.PyDO class attribute that controls whether to use fetchone or
fetchall for the associated table. (Leave fetchmany for the time being until
we've thought about it a bit more.)

3. For joins use the lowest ranked (fetchone < fetchall) of the strategies
specified by the constituent tables

[1] The provision of a __len__ method means that it can no longer actually be a
generator.

[2] I actually iterate over the cursor, which in turn uses 'fetchone'.


Hamish




-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click