[DB-SIG] "lists of tuples" vs. "tuples of tuples"

[Vernon D. Cole]

Recent versions of adodbapi do in fact return a result set ("Rows") object.
Since ADO requires a separate operating system call to fetch each row, and
since we can assume that the ADO result set is setting around in memory
somewhere, I did not want the space overhead of making an additional copy
of all of the result set, so each row is "lazy" fetched, when needed, as a
"Row" object. Individual rows can be selected by sequence or index
operations.
   Each "Row" object will then "lazy" fetch fields, which can be selected
by sequence, index, or mapping (by column name) operations, or accessed as
attributes (by column name). Each field datum is converted from internal
database format into an appropriate Python object at that moment,
optionally using a user-defined conversion.

Since both "Rows" objects, and "Row" objects, obey the sequence API, this
design satisfies the PEP requirements that we return a sequence of
sequences.  It will also do much more.  If the PEP had been written to
require a list of tuples, none of these other operations would have been
possible. I applaud the PEP authors for avoiding the temptation to
over-specify.

[By the way, both Rows and Row objects are made immutable, so that an
unwary programmer does not receive an unwelcome surprise by attempting to
alter data without using an SQL statement.]

>
> > We have made this more general in the DB-API to allow authors to
> > create e.g. result set objects which implement the sequence API
> > and row objects which also implement sequence API.
> >
> > I know several database modules which provide ways to have the
> > fetch methods return row objects, but I'm not aware of ones which
> > implement a result set object.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20150203/1624c157/attachment.html>