[DB-SIG] Result Set Inconsistencies

[Orr, Steve]

Thanks for your reply. Whilst I agree that the sequence type of a result
set is a relatively small point and is easily overcome I'm still
quizical on the "philosophy" behind a "flexible" API spec. See my
response to the "relaxed API spec is a feature" post.

Regarding the "burden" on the API authors... I don't see it. I looked at
some of their Python code and it looked like changing the result set
return type would be easy, but I could be wrong.

On a similar vein as regards cx_Oracle vs DCOracle2 result sets...
When I select a database column of datatype number, DCOracle2 returns
'1' where cx_Oracle returns '1.0' ... What's up with that? Is this a
failing of the spec or a failing of the module?

What about cursor.description? It seems like the second element could be
more consistent.

OK... It looks like I'm getting ready to start down the road to
developing my owna "middleware" framework. Any recommendations? (I guess
I'll take another look at your db_row package.) As I go down this road I
don't want to find myself saying, "Why oh why didn't I take the blue
pill?" ;-)  


-----Original Message-----
From: Kevin Jacobs [mailto:jacobs at penguin.theopalgroup.com] 
Sent: Wednesday, July 16, 2003 9:00 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:
> > 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!!!

The API authors were very careful about _not_ specifying what kinds of
sequence type.  The fact that you want to fill in some extra details
implies that your needs differ from those that the authors intended.
This is not to say that the spec is perfect, but this flexibility has
been appreciated by driver authors and has placed no undue burden on
application writers.

> 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?   :-)

Never!  I'm deeply unhappy about certain parts of the spec, and have
spent a great deal of time thinking about how to improve it
meaningfully.  

> 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.

My middleware framework currently supports 15 distinct DB-API drivers,
and none of them have the precise semantics that I want without glue
logic. 

> 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.

Sounds like every day for me.  I maintain over 500k lines of code in
several large financial applications that connect to many of the
databases you mention above, plus quite a few more.  And yes, I do have
to worry about driver idiosyncrasies, and frankly, the sequence type of
the result set is the least of my worries.

Now if you want to talk about more precise type specifiers, or sensible
semantics for bound query arguments, or a uniform type mapping
infrastructure, or anything else that really does impact complex and
heterogenious database enviornments, then you'll find I'm much more
interested.

-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