Ed Leafe writes:
> > I had originally set up the dBackend stuff to handle any
> > number of backend libraries that could just be 'dropped
> > in', but Ed didn't like that and switched to friendly names
> > such as 'mysql' instead of 'MySQLdb' - IOW the name of the
> > database instead of the name of the dbapi library.
> The aim is to simplify. Developers should specify the
> backend, and Dabo should handle the connection. We should
> default to a single adapter per database. Those who are more
> adventurous can code their own backends. I don't see any
> benefit in developing and supporting a dozen Postgres
> adapters.
While I see where you are coming from, if someone were to hand
us the code for a given adapter/database, then it should go
into Dabo so that others don't need to code it manually.
> Since our volunteer is a pgdb user, then that's what
> we'll use initially. Then if someone decides that some other
> adapter is better and wants to develop the backend file and
> show us why, then we could switch. But getting things to work
> in the first place is our main objective.
I think we should plan for pgdb and other connectors for
postgres - it is inevitable that we'll need to do that anyway.
I mean, if we start with pgdb and then later on decide that x
is better, are we really going to ditch the pgdb code and
replace with x, leaving the pgdb users high and dry?
Let's rename dbPostgreSQL.py to dbPostgreSQL-pgdb.py and put
code in dBackend to choose 'dbPostgreSQL-pgdb' if only
'postgressql' is named - IOW for now, 'postgressql' defaults to
pgdb. If we never add dbPostgreSQL-x.py, fine, we didn't break
anything, but I'm betting we will be adding it sooner or later
so let's build it in and establish a naming structure in case
we have to deal with the situation with other db's as well.
--
Paul McNett
http://www.paulmcnett.com
©2004 Paul McNett |
