[DB-SIG] Result Set Inconsistencies

[Mike C. Fletcher]

Kevin Jacobs wrote:
...

>>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've been looking into db_row today, very similar to the DBRow class in 
wxpytable (my own database abstraction framework), though that's a 
read-write system, and has no effort made to reduce memory overhead for 
individual rows.  Haven't yet decided whether to adopt db_row, or just 
transfer a few of the ideas.  Does look very nicely designed, anyway.  
May wind up taking the idea of making result-sets classes (they're 
stand-alone objects in my systems) at least.

>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.
>
Might help me.  I'm currently working on the object-relational part of 
my system to support my day-job (the company uses my library, but the 
library is open-sourced, so have to work on it off-hours).  Most of what 
the system provides at the moment is reverse engineering of database 
schemas from live databases on MySQL or PostgreSQL (i.e. get databases, 
tables, fields, constraints and indices), a "thick" API level that 
provides missing features for given database adapters (e.g. 
cursor.connection), and a fairly extensive set of objects for modelling 
schemas (either reverse engineered or generated directly, with 
SQL-generation support).  It's also got a few convenience elements here 
and there.

How many middleware systems do we have?  Is it possible that we need a 
Database-API on top of/beside DB-API to start reducing all the 
duplication, or is there really no common set of functions?

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/