On Jan 23, 2007, at 10:54 PM, Michael Bayer wrote: > > ugh, adds an extra conditional into every fetchone().... :)
Yeah, I know that's ugly. However, its definitely more visual overhead than actual overhead. Not to mention (as was said on the psycopg list) fetchone() should not be used many times in succession. Instead, a batch of rows should be fetched from the database (fetchmany)--it's a much more efficient usage of the database round- trip. It would be cool if ResultProxy.__iter__ did this automatically (i.e. grabbed a batch of rows) rather than using fetchone(). It would have a default batch size of something like 50 and a parameter to the query could override the batch size. ~ Daniel > > > On Jan 23, 2007, at 10:06 PM, Daniel Miller wrote: > >> I think I was the original person who had this problem. I found a bit >> of time to troubleshoot it and came up with a patch. >> >> The problem seems to be in ResultProxy when it does the metadata = >> cursor.description bit. cursor.description is returning None because >> the cursor has not had any rows fetched yet. If I do a >> cursor.fetchone >> () then cursor.description returns the expected result. So it looks >> like the solution here is to defer the metadata translation >> (construction of ResultProxy.props) until after some data has been >> fetched from the cursor. Patch attached (works for me, but not >> heavily tested). >> >> ~ Daniel >> >> >>> >> <server_side_cursors.patch> >> >> >> On Jan 23, 2007, at 11:22 AM, Michael Bayer wrote: >> >>> >>> ive heard of this one already, which is why the option is turned >>> off. >>> unfortunately I cant reproduce that here, so until someone wants to >>> figure out whats going on with that, not sure what I can do. >>> >>> we do have a ticket where someone commented that the server side >>> cursor >>> will cause things like "rowcount" to not function until the first >>> row >>> is fetched. I also do not observe that behavior on my >>> system...asked >>> the guy to post what cases cause that, big surprise, no response. >>> its >>> like our trac system is an oracle of shadowy myths and rumors. >>> >>> so if anyone wants to wrestle with the psycopg2 guys on this, and/or >>> figure out what the issue is, they seem to be generally not >>> excited by >>> server side cursors in the first place, in favor of just using >>> "LIMIT" >>> on your SQL so that there is little advantage to the server side >>> approach. from my point of view its not a critical issue since its >>> true, you can just use LIMIT as appropriate. >>> >>> >>>>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
