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