[DB-SIG] Proposed DB-API extensions

[Carsten Haese]

On Wed, 2008-03-19 at 13:23 +0100, Gerhard Häring wrote:
> ==> .execute(), .executemany() returning self.

+1. I agree that this is nice to have.

> ==> .execute(), .executemany() in connection object.

-0. Most queries get executed more than once. Not explicitly creating a
cursor to cache the statement negates the advantage of statement
caching, or it would make statement caching harder to implement.

This feature adds convenience for executing one-of queries, but I'm
worried people might use it in circumstances where creating a dedicated
cursor object would result in better performance.

> ==> __enter__ and __exit__ in the connection object...to automatically wrap database code in transactions

-1. InformixDB uses connection.__exit__ to close the connection, whereas
cx_Oracle uses connection.__exit__ to commit/rollback a transaction, so
the train for standardizing this has left the station already. Also, I
think explicitly committing or rolling back is a Good Thing in my
opinion.

I would however not be opposed to making a new connection method that
would return a "transaction context" object with the proposed behavior.
(For sqlite and cx_Oracle, this would merely be a shim that returns
self.) That way, the fact that a transaction is being managed is
explicitly visible, and we avoid the pre-existing incompatible use cases
for connection.__exit__ .

> ==> fetchscalar method in cursor object

+0. I have no problem with implementing this, but I don't see much use
for it myself.

Best regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net