Higher level constructs (was: [DB-SIG] Experiences with DB-API2.0 )

[Andy Dustman]

On Mon, 2002-06-24 at 06:37, Dittmar, Daniel wrote:
> Perhaps it would be a good idea to list the high level constructs:
> 
> fetchrow_hashref (from Perl):
>     returning a mapping from column names to 
>     values instead of a tuple
>  implementable through proxy classes: YES
>  my take: how about a callable object which acts like
>     a filter for every row. This would allow a lot of
>     other neat stuff like creating a Python object
>     from a row or fetching detail information for a 
>     master row

My approach on MySQLdb was to implement different row formats with
different Cursor classes. However, this is an interesting idea that is
totally trivial to implement, at least with my implementation...
 
> scrollable cursors (ODBC, JDBC):
>  implementable through proxy classes: NO, unless you
>     don't mind having the whole result set in memory

Some MySQLdb Cursors can scroll (those using CursorStoreResultMixIn),
for this exact reason.

> updatable cursors (ODBC, JDBC):
>  implementable through proxy classes: NO

Not sure what this entails...

> meta data (ODBC, JDBC):
>  implementable on top of DB API: YES, but
>     the code would be database specific
>  my take: instead of copying either
>     ODBC or JDBC, I would now prefer something
>     like http://dbdoc.sourceforge.net/ (see: 
>     simple Python API for inspecting DB schemas),
>     cursors are just too clumsy for this kind of data

The description attribute gives most of this data, but of course you
have to execute a query to get it (SELECT *) and deal with a result set.

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
"Cogito, ergo sum." -- Rene Descartes
"I yam what I yam and that's all what I yam." -- Popeye