[DB-SIG] Result Set Inconsistencies

[Orr, Steve]

> DB-API is there to enable database access -- not hold your hand or 
> write your applications for you. 
Oh c'mon. Nobody said anything about writing apps for anyone. I can
write wrappers to overcome the inconsistencies of the DB API
implementations but the point is that I should not have to and the spec
itself agrees with me in its second sentence!!! 

See Danny Yoo's response! See Kevin Cazabon's response!

Why be timid about the spec? Improvement was obviously needed between
1.0 and 2.0... Are you saying the spec is an immutable type and is
perfect as it stands?   :-)

Developing on one database engine is easy but when you're developing
apps to run on multiple database engines then you need consistency in
the API. Perhaps there's a complacency about this because there's not
much multi-database development going on. Picture a LARGE app (many
lines of code) written to support Oracle, Informix, DB2, SAPDB,
PostGreSQL, MySQL InnoDB, etc. and picture having to learn ALL the
idiosyncracies of all the DB API implementations and wrap something
around them to minimize database specific code. Now picture not having
to worry about it because the API spec was tighter in the first place. 

> ...life more difficult for DB-API driver authors...
This focus is wrong. The USERS of the API are important and should drive
the development of the spec to meet their collective needs. Whether
fetches return strings, tuples, or lists shouldn't impact API authors'
ability to deliver Python modules that perform well. The first two
sentences of the spec need greater emphasis!!

See Danny Yoo's response!
See Kevin Cazabon's response!

Eschew complacency. Continued improvement is the way to go.
Or just be timid, accept the status quo, and get busy with kludge
work-arounds. ;-)


-----Original Message-----
From: Kevin Jacobs [mailto:jacobs at penguin.theopalgroup.com] 
Sent: Wednesday, July 16, 2003 4:52 PM
To: Orr, Steve
Cc: db-sig at python.org
Subject: RE: [DB-SIG] Result Set Inconsistencies


On Wed, 16 Jul 2003, Orr, Steve wrote:
> Because results sets can either be lists or tuples (or strings?) the 
> API fails its stated purpose.

You don't see the major users of DB-API drivers resonating with this
argument, so this should be your hint that your use-case is not as
compelling as you think.  DB-API is there to enable database access --
not hold your hand or write your applications for you.  If you want
lists, and demand lists, then add the six extra characters and write:

  rows = list(cursor.fetchall())

If this is too much effort, then I can think of a several other ways to
make this easier -- and none of them make life more difficult for DB-API
driver authors.  In this case -- less is more.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com