<div class="gmail_quote">On Sat, Jan 9, 2010 at 1:00 PM, Dennis Lee Bieber <span dir="ltr"><<a href="mailto:wlfraed@ix.netcom.com">wlfraed@ix.netcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, 9 Jan 2010 10:28:31 -0500, Victor Subervi<br>
<div class="im"><<a href="mailto:victorsubervi@gmail.com">victorsubervi@gmail.com</a>> declaimed the following in<br>
gmane.comp.python.general:<br>
<br>
</div><div><div></div><div class="h5">> On Sat, Jan 9, 2010 at 10:14 AM, Iuri <<a href="mailto:iurisilvio@gmail.com">iurisilvio@gmail.com</a>> wrote:<br>
><br>
> > And you should use cursor.fetchall() instead of cursor in list<br>
> > comprehension:<br>
> ><br>
> > packageIDs = [itm[0] for itm in cursor.fetchall()]<br>
> ><br>
><br>
> Now, someone else on this list told me the other. Can you explain the<br>
> difference?<br>
<br>
</div></div>        Since a (one-liner) list comprehension is going to result in<br>
processing all the data, it may be faster to fetch all the data at the<br>
start. Depending upon the implementation of the database API, iterating<br>
over a cursor object to retrieve one record at a time may result in a<br>
hit on the database engine (some engines may hold the data in the server<br>
and only transmit it record by record unless explicitly asked for all of<br>
it -- and if the database server is on a different machine that could<br>
make for a lot of slow network traffic).<br>
<br>
        Also, you need to take the database locking system into account --<br>
until you not only read all the data, but commit the transaction (even a<br>
read-only transaction), the engine may lock any other user from<br>
accessing those records (and some engines may lock the entire table, not<br>
just records).<br>
<br>
        Iterating over a cursor may be useful if: 1) you have a really<br>
massive database and your query is not filtering the data to manageable<br>
levels (better done by looping over the query itself using limit and<br>
offset features to control how many records are returned in a batch); 2)<br>
it is a single user/single access database where locking data won't have<br>
an impact; 3) you need to use the data in each record to update or<br>
otherwise perform some other query on the database (though unless this<br>
is done within the same transaction you might still have locking<br>
issues).<br>
<div class="im"><br></div></blockquote><div><br>Wow! Thanks. I'll digest this over the weekend.<br>beno<br>
</div></div>