On Jan 24, 2007, at 8:17 AM, Daniel Miller wrote:
> 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. but ResultProxy is used for every database, not just postgres. > 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(). i dont think ResultProxy should make that assumption. its not always appropriate to prefetch rows. for example, I just committed a fix to Oracle so that it can use binary types. and as it turns out, Oracle result sets that contain LOBs have a restriction that I am accustomed to in other languages (and also i think Pygresql, another PG driver we dont support right now, has this restriction for some of its datatypes) - that the row you fetch contains "active" data, which is invalidated if you fetch the next row without fully reading all columns. typically BLOBs. we might work around this in a future release by prefetching the column data as well. however, im not comfortable with SA result sets totally fetching entire grids of results, in all cases, by default. i can see a lot of people having a problem with that, particularly if and when there is someday a DBAPI that actually implements result- fetching correctly and users would like SA to allow it to work to its full potential. so i would favor some flags on ResultProxy that get passed from the dialect for prefetching of rows, prefetching of columns. flags on the PG and Oracle dialects can affect these options but i like them being off by default. it would also be nice if ResultProxy didnt have any conditionals stuck into fetchone() if the flags are turned off, so im thinking maybe a __new__()/metaclass method of providing a "prefetching" subclass of ResultProxy (PrefetchResultProxy) might be a way to compartmentalize that complexity only when needed. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
