[DB-SIG] Re: db module wrapper
Jonathan M. Franz
jfranz at neurokode.com
Sun Aug 22 04:15:19 CEST 2004
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
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
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.
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.
NeuroKode Labs, LLC
More information about the DB-SIG