[DB-SIG] Result Set Inconsistencies

[Kevin Jacobs]

On Fri, 18 Jul 2003, Orr, Steve wrote:
> 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?

It could be a failing of the module, because the spec doesn't dictate what
to do with data.  The spec was written to be almost totally agnostic about
the data and type capabilities of the backend database.

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

>From my perspective, the type code is not usually the problem -- it is the
DB-API type objects that are too coarse grained.  It is important to know if
a column is a NUMERIC or a FLOAT type, and to distinguish DATE, TIME, or
DATETIME and INTERVAL types.

> 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?" ;-)  

It is very much worth the effort.  You get to do things your way, without
having to provide general solutions for every corner case.  db_row is a good
start, because it is orthogonal to many other extensions you may want to
add.  The only restiction is that it reqires the use of at least Python
2.2.3.

I'm also in the process of legally disentangling and open-sourcing large
portions of my own database abstraction framework.  Hopefully that will also
help, even if only by example.

-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