mapper's usage of fetchall() wont work with oracle binary cols

Issue #435 resolved
Mike Bayer repo owner created an issue

the new support for binary types in oracle, however limited, means that fetchall() cannot be used with those result sets. the Mapper will have to check a flag on the dialect (or do it in ResultProxy) indicating that fetchall() will either have to "fully" fetch the data (perhaps RowProxy could get a flag "prefetch", checks the values in the typemap for "requires_prefetch()" and does it, possibly), or that fetchall() should not be used.

Comments (7)

  1. Mike Bayer reporter

    id like to implement this using a new subclass of ResultProxy called PrefetchingResultProxy. the Connection object will query the dialect/executioncontext for arguments to be sent to the ResultProxy (this will require a new method on Dialect and/or ExecutionContext). ResultProxy will use an altered __new__() method or metaclass to receive the "should_prefetch" argument and then return PrefetchingResultProxy instead if the flag is True.

    The Oracle dialect should examine the typemap of the result set to be returned, determine if it contains LOBs, and if so then set the flag to true.

    The PrefetchingResultProxy should load all columns into memory each time fetchone() is called. if fetchmany() or fetchall() are called, the full grid of results should be fetched.

    the object also may gain some additional flags for usage with Postgres server side cursors, where the cursor.metadata is not available until fetchone() is called.

  2. Former user Account Deleted

    I've submitted a patch for this bug. fetchall() still doesn't work for result sets returned from Connection.execute_text, since convert_result_value() doesn't do anything in that case.

  3. Mike Bayer reporter

    ian -

    this patch looks excellent ! i dont think you could have done it any closer to what i was thinking. I will try to have this committed later today.

  4. Log in to comment