[DB-SIG] Re: db module wrapper

[Randall Smith]

Jonathan M. Franz wrote:
> 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
Developers are certainly spread thin and when I saw your post, my first 
thought was maybe I should drop what I'm doing and use PDO.  It is 
similar in that they both try to hide differences in underlying modules. 
  There is a difference in the scopes of the projects.  PDO is ADO for 
Python.  The scope of my project is to maintain a DB API V2 interface 
while hiding module differences.  Although we do have some duplicated 
effort, there are several differences.  I just want my DB API2 code to 
work with all modules.  You want an ADO interface.
> 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") 
I don't plan to modify connection parameters.  The thought being that 
when you switch databases, you have to change this anyway.
> 
> 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.
When discussing this, people had different opinions.  Therefore, I'm 
enabling all 5 paramstyles.
> 
> - 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.
The popular opinion was to use Kevin Jacob's idea:
http://mail.python.org/pipermail/db-sig/2003-April/003345.html

I say popular.  Ian and Kevin suggested it.
> 
> ==============
> 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.
Yea.  That does sound difficult.  Editable resultsets are nice.
> 
> Do you plan on editable resultsets in your module?
Definitely not.  To much work.  I'm mainly programming to API 2.  Config 
files are used to adapt modules that do not completely comply.  In 
theory, a module that is API2 compliant needs no config.
> 
> More soon as I catch up further with the thread.
> 
> ~Jon Franz
> NeuroKode Labs, LLC
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> http://mail.python.org/mailman/listinfo/db-sig

I'm all about not duplicating effort.  I'm not a glutton for needless 
work.  Whether or not my project is made public and maintained depends 
on public interest.  Are our projects similar enough that I should drop 
mine?  I don't know.  I'm not looking for an ADO interface, so I plan on 
using what I have created.  Others may think there is too much 
duplication.  In that case, I'll use it, but not publish/maintain it. 
Though, as judged from the list, there seems to be interest.  So my 
current plans are to put it in Sourceforge CVS.

Randall