[DB-SIG] Re: db module wrapper

[Jonathan M. Franz]

Randall Smith wrote:

> 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.

Not really ADO for python, just more ADO/JDBC/delphi-data-objects like 
:)  No worries on keeping yours separate - I was just referencing your 
reinventing the wheel statement, just very late :) ,

>> 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.

We found that we almost had to - some modules accept their arguments by 
name, and can use the **kwargs trick, some don't and thus can't :(  
Except for the name of the primary arguments (module, user, passwd, db), 
we don't modify the args in any way versus the underlying module - and 
even then we're just changing the names.

>> - exceptions
>
> The popular opinion was to use Kevin Jacob's idea:
> http://mail.python.org/pipermail/db-sig/2003-April/003345.html

That looks good - for PDO, we didn't need to keep the original API's 
exception names, hence our wrapper method.

>> Do you plan on editable resultsets in your module?
>
> Definitely not.  To much work.  

I know the feeling :)   I'm back around to where it's not so bad now - 
but that was after ripping things out and restructuring things, adding 
query objects, etc - so the solution isn't so bad, but the work to get 
to the sane solution and get everything needed for it to not be insane 
was a bear.

Note to Marc: the clarifications as to the descriptor fields and their 
meanings we discussed on the python list a long time ago was a big help 
- but those clarifications are still outstanding in the spec itself.  
Should I submit a doc patch?

> 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.

We're pretty much at the same point.  A word of warning - watch out for 
assumed behaviors.  For example, some modules return the number of rows 
affected by an execute as the return value of the execute; Others do 
not.  The standard just states that return values are undefined - hence 
the ambiguity and different behavior.

> 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.

Sounds like a plan, good luck with it, and I'll await the posting of the 
code!

~Jon Franz
NeuroKode Labs, LLC