[DB-SIG] Re: db module wrapper

[Jonathan M. Franz]

Well, I'm late to this conversation - so I apologize if my points have 
already been made.

What Randal is doing is very similar to what we're working towards for 
PDO 2.0 - PDO _is_ actively maintained and promoted, btw.  Heck, back in 
the 1.0.2 days we even were thrown on some CDs that linux enterprise 
magazine in europe distributed.  Frankly, we've always been surprised by 
the cold reception we've gotten on the db-sig mailing list whenever we 
raise a concern or mention our module.  Perhaps we've been too 
argumentative about things we feel the dbapi is lacking?
Some of the arguments earlier this year when Guido spoke up were things 
we took very seriously - but the conversation about what todo for dbapi 
3.0 died for no  apparent (to me) reason.

Anyway, some thoughts on ways we do things now in pdo, and how they 
intersect with Randall's ideas:
(cross pollination of ideas is always a good thing)

- connection strings
We use a single string to hold connection data, with the core parameters 
standardized (dbapi-module,username, password, database), and the rest 
given in a module specific way, but all formated into a single string 
thusly:
aConnection = 
pdo.connect("module=someModule;user=foobar;passwd=mypass;db=myDB;host=localhost")
This should be _very_ familar to ADO users.

- parameter formating
Currently we just use the underlying dbapi module's quoting method - but 
for 2.0 (which we hope to beta soon!) we're moving towards a :named 
style, using a modified form of the recipe for style unification at 
ASPN.  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278612
We'd considered a positional ('?') style, but found it too limiting.  
The first time you do a insert or update with 20 ?s in it, you get the 
feeling that it is rather awkward.
Of course, you could allow the user to switch styles on the fly - it'd 
just be an extra set of conversion functions.

- exceptions
We already have implemented a unified exception system - PDO contains 
it's own exceptions, and the textual description contains the underlying 
exception and the underlying exception's text - allowing for users to 
capture one set of exceptions and yet giving them all the detail they 
need to find out why the dbapi module.  It's easy to implement, just 
take a look and steal away.

==============
Things to ponder:
One thing that made my life rather painful when working on PDO 2.0 was 
that the underlying type systems in dbapi modules are so different.  The 
implementation of editable resultsets (no more update queries!) required 
some interesting juggling to bring the underlying types into the current 
namespace in a usable way.

Do you plan on editable resultsets in your module?

More soon as I catch up further with the thread.

~Jon Franz
NeuroKode Labs, LLC