Ed Leafe writes:
> On Jun 30, 2004, at 6:03 PM, Paul McNett wrote:
> > All I want to see is:
> >
> > dbPostgresSQL-pgdb.py
> > dbPostgresSQL-x.py
> >
> > that implement the interfaces to the different db adapters
> > for postgres
> Except for the "import xxx" line, they should all be
> identical. Think about it: the backend is what varies. All
> adapter code for PostgreSQL should form the exact same
> strings quoted the exact same way, should escape the exact
> same characters in the exact same way, should call the exact
> same code to begin/commit/rollback transactions, etc. The
> only thing that should change is the name of the library to
> import.
It sure could be that the only line that changes is the import,
and it could also be that there are other lines that need to
change as well.
Why not cover all the bases and just use subclassing to avoid
duplicating code if that's your main concern.
> > Why force them to rename a file (and have to remember to do
> > that again and again as they upgrade Dabo) instead of
> > giving them an explicit BackEndName to use? Does it really
> > complicate things to use the name of the dbapi in the
> > BackEndName?
>
> Yes, it does complicate things, because you're now
> programming to the exception. 99.9% of all Dabo users will be
> able to use the standard libs.
Some will want to use pgdb, others will want to use x. Dabo
should support both 1) because it can be easily handled and 2)
because it is the right thing to do.
> Those few who want to do
> something different can take care of the tiny effort involved
> in renaming the file, or simply changing the single import
> line of the existing file.
What if 33% of postgres people use pgdg, 33% use x, and 33% use
y? It is hardly programming to the exception to handle a few
corner cases: it is providing full support for whatever adapter
people want to use.
> And once we get out of this early
> alpha stuff, this stuff isn't going to be changing very
> often, if at all, so it's not like this will be a weekly
> chore.
Agreed, my point exactly.
--
Paul McNett
http://www.paulmcnett.com
©2004 Paul McNett |
