[DB-SIG] Remaining issues with DB API 2.0

Andy Dustman adustman@comstar.net
Mon, 29 Mar 1999 01:34:58 -0500 (EST)


On Sun, 28 Mar 1999, Greg Stein wrote:

> Andy Dustman wrote:
> > ...
> > > > The part about multiple paramstyles should not be included. A database
> > > > should take just one style and be done with it. Higher levels can
> > > > perform the appropriate mappings.
> > >
> > > Andy ?
> > 
> > Yeah, sure. There's no database that supports multiple styles at this
> > time, though the new MySQLdb could, since it is using the % string
> > operator anyway. Maybe I'll slip that in as a separate method or
> > something.
> 
> That just doesn't feel right, but hey... it's your module :-)
> 
> (IMO, the Python way of "one way to do things" keeps things clean and
> simple)

So long as the API definition allows me to pass execute a dictionary (or
other mapping object), I'd rather do it that way. Assuming I even
implement it. It's not hard, but I don't have a compelling reason to do
it...

> This is what I've been pushing for. You SHOULD be able to define the
> connect() HOWEVER you want. It changes so dramatically from one database
> to the next that we should NOT attempt to specify anything about it
> beyond "connect() takes some parameters". Keyword, positional, what
> names, what defaults, etc should not be specified.
> 
> My simple counterpoint is a DBM database that simply takes a filename.
> And I hope that I don't have to point out that DBM databases *are* in
> the scope of the DB-SIG efforts and (hopefully) within the design space
> of DBAPI.

I would be happy if the parameters to connect were undefined (completely
database-dependent) so I could do whatever I want with them. There's too
much database diversity to come up with one set of parameters.

With everything else, though, it seems like we need to aim for an
idealized database interface that emulates stuff that doesn't exist where
feasible and raises exceptions when impossible. The examples previously
mentioned were cursors, which MySQL doesn't have, but which are easily
emulated, and rollback, which must always fail somehow.

Even so, I'm not sure how we would wrap dbm, gdbm, or bsddb to be
compatible with the API, as they have no query language, no (or one)
table, and no columns! Perhaps the wrapper could parse a little SQL,
ignore the specified columns, and just pickle whatever parameters it
finds. It'd be tough, though. I think I'd stick with the shelf
interface... (I actually have a module, SQLDict, that wraps a
dictionary-like interface around a DBI-compatible connection object...
That direction of abstraction is a little easier to do...)

-- 
Andy Dustman  (ICQ#32922760)    You should always say "spam" and "eggs"
ComStar Communications Corp.                 instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D   in Python examples. (Mark Lutz)