[DB-SIG] Use of record sets

[M.-A. Lemburg]

John Shafaee wrote:
> 
> This may be a stupid question, but is the dtuple.py specs. part of the Python
> DB API? I do not have access to the older SIGs, but looking over the current
> API interface docs I did not see anything mentioned about such a class.
> 
> Actually, the concept of viewing DB results as records has been around for much
> longer than Python itself, no argument there. I am certain that at this time
> there are a number of Python implementations out there; all equally good and
> useful. Just in the past DB-SIG posts there were two different implementations
> mentioned (Record and SQLDict).
> 
> However, I think there is a need to standardize on this concept (if it has not
> already been done and/or I just missed it). I believe that the most appropriate
> definition for this concept would be in the Python DB API. It would be great if
> all implementations of the DB API would provide a facility for treating results
> as record sets.
> 
> So, as there are many different implementations of converting fetchall() results
> into records sets, there isn't a standard one that we can expect when working
> with a Python DB module.

dtuple.py works with all DB API compliant database interfaces.
There is really no need to add any such mechanism to the DB API
spec. itself, since writing wrappers which enable this features
in one of the possible ways is easy and can be done by the application
programmer rather than the interface author.

Note that mapping columns to column names is not necessarily
a 1-1 mapping. Some DBs may not even support querying column
names in result sets.

> Best,
> John S.
> 
> Greg Stein wrote:
> 
> > Euh... there is already a module to handle result sets as tuple,
> > dictionaries, or attributed objects. It was written over five years ago :-)
> >
> > http://www.lyra.org/greg/python/
> >
> > Right around the middle of the page: dtuple.py
> >
> > Cheers,
> > -g
> >
> > On Wed, Apr 04, 2001 at 06:11:37PM +0200, Dittmar, Daniel wrote:
> > > > result = curs.fetchone()
> > > > print "Found id '%s', first name '%s' and last name '%s'"%( result[0],
> > > result[1], result[2] )
> > >
> > > vs.
> > >
> > > > print "Found id '%s', first name '%s' and last name '%s'"%( result['id'],
> > > result['first_name'],
> > > >   result['last_name'] )
> > >
> > > How about
> > >
> > > id, first_name, last_name = curs.fetchone ()
> > > print "Found id '%s', first name '%s' and last name '%s'"%( id, first_name,
> > > last_name)
> > >
> > > or better still
> > >
> > > for id, first_name, last_name in curs:
> > >     print "Found id '%s', first name '%s' and last name '%s'"%( id,
> > > first_name, last_name)
> > >
> > > This is of couse not directly an argument against using strings as a column
> > > index (DBI has them, JDBC has them).
> > >
> > > There is one annoying property of SQL in this context: identifier are
> > > converted to uppercase unless quoted. Should the UserDict mimic this
> > > behaviour by trying both the actual string and the uppercase version?
> > >
> > > And how about returning row objects. That would allow .dot notation (if the
> > > column names are valid Python identifier):
> > > print "Found id '%s', first name '%s' and last name '%s'"%( result.id,
> > > result.first_name, result.last_name)
> > >
> > > My personal preference: 'for id, first_name, last_name in curs:'
> > >
> > > Daniel
> > >
> > > --
> > > Daniel Dittmar
> > > daniel.dittmar@sap.com
> > > SAP DB, SAP Labs Berlin
> > > http://www.sapdb.org/
> > >
> > > _______________________________________________
> > > DB-SIG maillist  -  DB-SIG@python.org
> > > http://mail.python.org/mailman/listinfo/db-sig
> >
> > --
> > Greg Stein, http://www.lyra.org/
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://mail.python.org/mailman/listinfo/db-sig

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/