[DB-SIG] annotated 1.1 spec / feedback

[M.-A. Lemburg]

Greg Stein wrote:
> 
> 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.

All true, but due to the way methods are "published" in C
dynamically making them available is not easily done.

> 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.

Right. In ODBC you can even set the transaction level on a per
connect basis.

The attribute based approach is still easier to implement, though...

Note that for ODBC the standard transaction behaviour is AUTO COMMIT,
meaning that the transaction is committed for every executed statement.
Calling .rollback() on such a connection wouldn't show any effect
even if the database does support transactions.

> 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?).

Agreed. This is not clear enough yet. People tend to forget
the possibility of using bind parameters: they simple use 'statement %s'
% (myparam,). Of course, this can cause lots of trouble with e.g.
binary data or multi KB sized data.

How should the parameter handling be indicated ? AFAIK, there are
two common ways: ?,?,? and :1, :2, :3...

.marker:  '?' or ':%i' ???

-- 
Marc-Andre Lemburg                               Y2000: 290 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------