[DB-SIG] annotated 1.1 spec / feedback

[Greg Stein]

M.-A. Lemburg wrote:
> 
> Andy Dustman wrote:
> >
> > The only other thing I worry about somewhat is the handling of
> > transactions. On a db without transactions (MySQL), commit() can simply do
> > nothing. rollback(), however, is another matter. I tend to think that
> > rollback() on a database without transactions should raise some kind of
> > exception. Perhaps it simply should not be defined so that an
> > AttributeError is raised, so the application can at least try to take some
> > corrective action.
> >
> > Another possibility is some kind of capabilities object which the
> > application can use to determine what features are available. One obvious
> > capability is the presence or absence of transactions. Another might be
> > the type of parameter substitution used by the query language. I'm not
> > really sure how useful this would be. Every database has it's own quirks,
> > it seems, and it's probably not possible to work around all of them.
> > However, at least knowing that transactions aren't available might at
> > least let some alternate code work around this.
> 
> We could add a module global 'transactionlevel' to make this
> information available with values:
> 
>         0       - database does not support transactions
>         non-0   - bit field containing database specific information
>                   about how transactions are implemented
> 
> ODBC has an API to query database/driver capabilities called
> SQLGetInfo which provides the above under the id
> SQL_DEFAULT_TXN_ISOLATION. You may want to look at the ODBC
> docs at:
>         http://www.solidtech.com/support/pg/httoc.htm
> To get an impression of what the above bit field could look
> like.
> 
> As for .rollback() I'm not sure whether raising an exception
> would help much: transactions are a very basic concept and
> a work-around is likely not going to be possible by writing
> a simple try-except handler.

I think it would be nicer to omit the commit/rollback methods if they
are not supported. A simple hasattr() test will provide the information
that you need.

The "os" module operates the same way: if a function is not supported,
then it is simply omitted (rather than raising some kind of error).

Starting to define bitfields will just get us in trouble, I think.

A question does arise: for the ODBC module, it doesn't know until a
connection is made whether commit/rollback is supported. In that case,
how do we reset commit/rollback based on the dynamic information queried
via the connection? hmm... I would recommend that if a DB module needs
dynamic determination of rollback capability, then it should dynamically
make commit/rollback available. For example, if those two methods are in
C, then the module checks a flag (set at connection-instantiation, or
lazily at the first getattr for commit/rollback) in the getattr
function. If the methods are going to be in Python, then a __getattr__
is necessary.

Note that something like transactionlevel would be connection-based, not
module-based. I don't recommend going for yet another flag like this,
when we have a "capabilities" style via the presence/absence of a
method.

The query substitution is a good one. I don't have any particular ideas
there. I do think that we need to clarify the execute() statement,
though, that the parameters imply input binding. Not string
substitution. There's a big difference in behavior between the two (e.g.
does the client need to quote parameter values?).

Cheers,
-g

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