[DB-SIG] API Enhancements

Greg Stein gstein@lyra.org
Mon, 01 Mar 1999 05:11:55 -0800

M.-A. Lemburg wrote:
> Greg Stein wrote:
> >...
> > Is it possible to get this document (or a version of it) red-lined so
> > that we can see the differences from the 1.0 document? I can generally
> > see the differences, but it would be better to clarify it.
> > [ I'd be willing to construct the red-lined version if you'd like
> > assistance ]
> [Meta: is there a tool available to aid in doing this, e.g. a
> HTML aware diff ?]

Don't know of one.

> I would appreciate you helping with it, since I'm pretty much
> burried in work.


> > > 1. Threading
> > >
> > > The API spec should make some notes about the scope of thread
> > > safety imposed on the interfaces. Thread safety could be given
> > > at module level (threads all use the same module, but maintain
> > > their own connections), connection level (threads share modules
> > > and connections, cursors are not shared between threads) and
> > > cursor level (threads share module, connections and cursors).
> > >
> > > The last level is probably not feasable, but I think connection
> > > level could be reached.
> >
> > A discussion in the API would be good. I might even say that a module
> > could export an attribute that states which level is supported. For
> > example, I know that many Win32 ODBC drivers are NOT thread-safe at all.
> > You must open a connection per thread.
> How about a constant defined as module global:
> threadsafety:
> 0 - module level
> 1 - connection level
> 2 - cursor level
> If it's not available, then module level should be assumed.

Strings constants are easy in Python. Would strings make more sense?
'module', 'connection', and 'cursor' ?

A module global stating the specification level would also be handy.
'1.1' for modules conforming to the DBAPI 1.1 spec. If the global is not
present, then the module is a 1.0 module.

> ...
> Hmm. This takes us to another project: that of turning database
> support for Python into packages... I'm currently building all my
> extensions this way: there is usually one C extension and a whole
> bunch of Python scripts which build upon its functionality. The user
> always accesses the package through the main door :-) and thus does
> not see what actually happens at the back end.
> Database interfaces could use a similar approach, e.g. code
> the catalog interface in Python using the C extension to access
> those special tables.

Sure, but I'd say that the spec for any package is separate from the
DBAPI spec for C modules. In general, it seems more difficult for
C-level support to occur, than Python-level. IMO, providing a clean spec
which is easy to implement really helps.

> > >...
> > > 4. Optional named cursors
> > >
> > > The cursor constructor should be allowed to have an optional
> > > argument for the cursor name. This is useful for UPDATEs.
> >
> > I do not understand the use or operation of this, and how it would
> > benefit an UPDATE. Could you elaborate?
> In ODBC, for example, the ODBC driver uses generated names for
> all cursors. Now, it is sometimes useful to be able to refer to
> the cursors under known names, e.g. to do UPDATE ... WHERE CURRENT
> OF <cursorname>. The optional argument allows this by providing
> an explicit name.

But this update is passed to the execute() method of the cursor object
that you're talking about, isn't it? Or do you create a second cursor,
which updates the record currently indicated by the first cursor?

Isn't that kind of technique a bit difficult without a rigorous
specification of the module's fetching behavior? Just because I called
fetchone() doesn't mean the cursor is sitting on the first record... an
array-fetch may have occurred, and the cursor is 90 rows later.

By naming a cursor, it would seem that any array-fetching would need to
be disabled so that a program can actually determine what record is
being referenced by the cursor. For safety, it may even be prudent to
disable fetchmany() and fetchall().

Finally: is there a performance gain to the named-cursor technique?
(compared to an UPDATE ... WHERE <primary-key> = <value>)

Oh... a question about the nextresult() method. Why is that exposed?
Shouldn't the module just automatically move to the next result set
inside the fetch* methods? I don't see the benefit of exposing that to
the user. It seems an artifact of the underlying database interface,
rather than a useful user-level concept.


Greg Stein, http://www.lyra.org/