Re: row_factory and DictCursor

On Wed, Jun 3, 2009 at 12:30 PM, James Henstridge <[email protected]> wrote:
> On Tue, Jun 2, 2009 at 11:26 PM, Joel Nothman
> <[email protected]> wrote:
>> What do you think of these proposed changes? Unfortunately, it would be hard
>> to make them backwards compatible, but if few people have written their own
>> row factories according to the old interface, then the available ones
>> (DictRow, RealDictRow) will be easy to modify.
>
> I think it sounds like a good idea (especially if it can simplify the
> core code to only have to work in terms of tuples).  Compatibility is
> a concern though, so it'd be useful to know whether anyone is actively
> using this extension mechanism outside of the DictConnection /
> RealDictConnection classes.
>
> If we do change the API, I think it'd be best to make it exactly the
> same as the pysqlite API if possible -- that should make it more
> useful for apps that try to support multiple database backends.
>
> As for the _build_fields() bit, psycopg offers a read only rownumber
> attribute on the cursor that tells you where in the result set you
> are.  Perhaps a row factory could assume that if rownumber is not 0,
> then the previous cached field mappings are still valid?

Here is a quick example of the sort of thing I was thinking of using rownumber:

class DictConnection(_connection):
    def cursor(self, name=None):
        cursor = super(DictConnection, self).cursor(name)
        field_names = []
        def row_factory(cursor, data):
            # Update field descriptions if it is a new result set.
            if cursor.rownumber == 0:
                field_names[:] = [info[0] for info in cursor.description]
            return dict(zip(field_names, data))
        cursor.row_factory = row_factory
        return cursor

Something similar would be possible with for a namedtuple
implementation.  In both cases you can get by without a cursor
subclass, which is probably a plus.

James.